I don't know if anyone looked at the time series (not trend) or spectrum of the Microphone after installation, but it looks bad and featureless to me. Is the Microphone broken?
This shows the spectrum from early this morning and again from tonight. You can see that it is bi-stable in its noise properties. This thing is busted; we're now removing it from the PSL so that it doesn' light it self on fire.
I had noticed something wonky with the microphone, but neglected to elog it. I had tested it after installation by playing a sine wave from my laptop and looking at the signal on the PSL table, it worked fine. But you can see in the attached minute trend plot that the signal characteristics changed abruptly ~half a day after installation, and never quite recovered.\
Rana motivated me to take a step back and reframe the objectives and approach for this project, so I am collecting some thoughts here on my understanding of it. As I write this, some things still remain unclear to me, so I am leaving these as questions here for me to think about...
and come up with the best loop that meets all our rquirements? What constitutes the "best" loop? How do we weight the relative importance of our various requirements?
For the specific problem of making the MCL feedback loop better, the approach I have in mind right now is the following:
My immediate goal is to have the Simulink model updated.
Thoughts/comments on the above will be appreciated...
More testing of fb1 today. DAQ DOWN UNTIL FURTHER NOTICE.
Testing Wednesday did not resolve anything, but Jonathan Hanks is helping.
In working on automatic DARM loop design, we have this code:
the things in there like mkCost*, etc. have examples of the cost functions that are used. It may be useful to look at those and then make a similar cost function calculation for the MCL/MCF loop.
Since the "stablizer box" doesn't really need to stabilize, it just needs to amplify, I decided to replace it with an off the shelf amplifier we already had, ZHL-2. I worked on getting it set up today, but didn't connect anything so that people have a chance to give some feedback.
So, I think the remaining thing to do is to connect the splitter to ASC out and to the line to the EOM, the +24V supply to the amplifier, and the 29.5 MHz input to the attenuator. I wanted to wait on this to get confiration that the setup is OK. Eventually we can put all of this in a box.
Also, I noticed that in the clear cabinet with the Sorensens next to this rack, the +24 V unit is not supplying any voltage and has a red light that says "OVP."
The bottom 5 cable connections from Sat-Amp to Whittering Filter at 1X5 were clamped today.
Had to reboot c1psl, c1susaux, c1auxex, c1auxey and c1iscaux today. PMC has been relocked. ITMX didn't get stuck. According to this thread, there have been two instances in the last 10 days in which c1psl and c1susaux have failed. Since we seem to be doing this often lately, I've made a little script that uses the netcat utility to check which slow machines respond to telnet, it is located at /opt/rtcds/caltech/c1/scripts/cds/testSlowMachines.bash.
The script can be executed by ./testSlowMachines.bash.
I've edited Rana's Simulink model to reflect the current IMC servo topology (to the best of my understanding). I've tried to use Transfer Function blocks wherever possible so that we can just put in the appropriate zpk model in the script that will linearize the whole loop. I've also omitted the FSS SLOW loop for now.
I've been looking through some old elogs and it looks like there have been several modifications to both the MC servo board (D040180) and the TT FSS Box (D040105). I think it is easiest just to measure these TFs since the IMC is still down, so I will set about doing that today. There is also a Pomona Box between the broadband EOM and the output of the TT FSS box, which is meant to sum in the modulation for PMC locking, about which I have not yet found anything on the elog.
So the next steps are:
If anyone sees something wrong with this topology, please let me know so that I can make the required changes.
It is more accurate to model the physical frequency noises at various places.
cf. See also 40m ALS paper or Shigeo Nagano PDH thesis on https://wiki-40m.ligo.caltech.edu/40m_Library
- The output 4 should be "Laser frequency"
- Seismic path should be excluded from the summing node
- The output after the PMC: "Laser frequency after the PMC"
- "Laser frequency after the PMC" is compared (diffed) with the output 1 "mirror motion in Hz"
- The comparator output goes to the cav pole, the PD, and the PDH gain: This is the output named "PDH Error"
- Tap a new path from "Laser frequency after the PMC" and multiply with the cav pole (C_IMC)
- Tap a new path from "Mirror motion" and multiply with the cavity high pass (s C_IMC/omega)
- Add these two: This is the output named "Frequency noise transmitted by IMC"
A few minutes back, I glanced up at the control room StripTool and noticed that the MCREFL PD DC level had gone up from ~0 to ~0.7, even though the PSL shutter was closed. This seemed bizzare to me. Strangely, simply cycling the shutter returned the value to the expected value of 0. I wonder if this is just a CDS problem to do with c1iool0 or c1psl? (both seem to be responding to telnet though...)
Since things look to be back to normal, I am going to start with my characterization of the various TFs in the IMC FSS loop...
I tested the amplifier with the Agilent network analyzer and measured 19.5 dB of gain between 29 and 30 mHz. The phase only changed by 1 degree over this same 1 MHz span. Since everything seems to be in order I'll hook it up this afternoon, unless there are any objections.
received this note: at 4:11pm Tuesday, Feb 7, 2017
Date: Wednesday, February 8, 2017
Time: 7:30 AM – 8:30 AM
Contact: Rick Rodriguez x-2576
Pasadena Water and Power (PWP) will be performing a switching operation of the
Caltech Electrical Distribution System that is expected to be transparent to Caltech,
but could result in a minor power anomaly that might affect very sensitive equipment.
IMPACT: Negligible impact......?
There may be temporary power interruption tomorrow!
PS:we did not see any effect
I set everything up and connected it as shown on the block diagram attached to the previous entry, with the exception of the DC power. This is becuase there is no place open to connect to on the DIN rail where the DC power is distributed, so the +24V power will have to be shut off to the other equipment in 1X1 before we can connect the amplifier. (The amplifier is in 1X2, but the DC power distribution was more accessible in 1X1.) I also added 3 new +24 V clips with fuses despite needing only one, so next time we need to connect something new it's not such a hassle.
The RF distribution box where the 29.5 MHz signal originates should not be turned on until the amplifer has DC power. Since we may have a power interruption tomorrow, the plan is to wait until things are shut down in preparation, and then shut off anyhting else necessary before connecting the new clips on the rail to the existing ones.
After fighting with Altium for what seems like an eternity I have finished putting my vision of the vme crate backplane adapter board into an electronic format. It is dimensioned to fill the back space of the crate exactly. The connectors are panel mount and the PCB attaches to the connectors with screws, such that the whole thing will be mechanically much more stable than the current configuration. A mounting bracket will attach to horizontal struts that need to be installed in the crates, mechanical drawings to follow.
The ITMX oplev beam is clipping. It will be corected with locked arm
Quick summary elog, details to follow. I did the following:
The measurements I have look reasonable. But I had a hard time trying to look at the schematic and determine what is the appropriate number and locations of poles/zeros with which to fit the measured transfer function. Koji and I spent some time trying to go through the MC Servo board schematic, but looks like the version uploaded on the 40m DCC tree doesn't have changes made to it reflected (we compared to pictures on the 40m google photos page and saw a number of component values were different). Since the deviation between fit and measurement only occurs above 1MHz (while using poles/zeros inferred from the schematic), we decided against pulling out the servo board and investigating further - but this should be done at the next opportunity. I've marked the changes we caught on a schematic and will upload it to the 40m DCC page, and we can update this when we get the chance.
So it remains to fit the other two measured TFs, and add them to the Simulink model. Then the only unknown will be the PDH discriminant, which we anyway want to characterize given that we will soon have much more modulation.
Data + plots + fits + updated schematics to follow...
http://www.amscope.com/3-5x-180x-boom-stand-trinocular-zoom-stereo-microscope-with-144-led-ring-light-and-10mp-camera.html will be ordered today.
The actual unit we are getting has lockable zoom for better repeatability after calibration: SM-3NTPZZ-144
I'd like to fix a few things at 1X1 when we plug in the new amplifier for the 29.5MHz modulation signal.
Steve has ordered rolls of pre-twisted wire to run from 1X1 to the PSL table, so that part can be handled later.
But at 1X1, we need to tap new paths from +/- 24V to the DIN connectors. I think it's probably fine to turn off the two Sorensens, do the wiring, and then turn them back on, but is there any procedure for how this should be done?
Here are the details as promised.
Attachment #1: Updated simulink model. Since I haven't actually run this model, all the TF blocks are annotated "???", but I will post an updated version once I have run the model (and fix some of the questionable aesthetic choices)
Attachment #2: Measured and fitted transfer functions from the "IN1" input (where the demodulated MC REFL goes) to the "SERVO" output of the MC servo board (to FSS box). As mentioned in my previous elog, I had to put in a pole (fitted to be at ~2MHz, called pole 9 in the plot) in order to get good agreement between fit an measurement up to 10MHz. I didn't bother fitting all the high frequency features. Both gain sliders on the MEDM screen ("IN1 Gain" and "VCO gain") were set to 0dB for this measurement, while the super boosts were all OFF.
Attachment #3: Measured and fitted transfer function from "TEST 1 IN" to "FAST OUT" of the FSS box. Both gains on the FSS MEDM screen ("Common gain adjust" and "fast gain adjust") were set to 0dB for this measurement. I didn't need any ad-hoc poles and zeros for this fit (i.e. I can map all the fitted poles and zeros to the schematic), but the fit starts to deviate from the measurement just below 1 MHz.. perhaps I need to add a zero above 1MHz, but I can't see why from the schematic...
Attachment #4: Measured TF from "TEST 1 IN" to "PC OUT" on the FSS box. MEDM gains were once again 0dB. I can't get a good fit to this, mainly because I can't decipher the poles and zeros for this path from the schematic (there are actually deviations from the schematic posted on the 40m DCC page in terms of component values, I will try and correct whatever I notice) . I'll work on this...
Attachment #5: Data files + .fil files used to fit the data with LISO
Most of the model has come together, I am not too far from matching the modelled OLG to the measured OLG. So I will now start thinking about designing the controller for the MCL part (there are a couple of TFs that have to be measured for this path).
Lydia finished up installing the new RF amplifier, and will elog the details of the installation.
I wanted to try and measure the IMC OLG to compare against my Simulink model. So I went about performing a few checks. Summary of my findings:
TBC tomorrow, I'm leaving the PSL shutter closed and the RF source off for tonight...
To install the replacement amplifier, I did the following:
Still to be done:
c1iool0 was down again. Rather than key the crate, this time I just pushed the reset button on the front and it came back.
As move towards the wonderfulness of AcroMag, we also have to buy a computer to handle all of these IOCs. Let's install the new c1iool0 over by the SUS computer.
To remind myself about how to put filter caps on the mini-circuits RF Amps, I looked at Koji's recent elog. Its mostly about op-amps, but the idea holds for us.
We want a big (~100 uF) electrolytic with a 50V rating for the +24V RF Amp. And then a 50V ceramic capacitor of ~0.1 uF close to the pins. Remember that the power feed through on the Mini-circuits case is itsself a capacitive feedthrough (although I guess its a ~100 pF).
Later, we should install in this box an active EMI filter (e.g. Vicor)
Rana and I spent some time looking at the IMC demod board earlier today. I will post the details shortly, but there was a label on the front panel which said that the nominal LO level to the input should be -8dBm. The new 29.5MHz routing scheme meant that the LO board was actually being driven at 0dBm (that too when the input to the RF distribution box was attenuated by 5dB).
An elog search revealed this thread, where Koji made some changes to the demod board input attenuators. Rana commented that it isn't a good idea to have the LO input be below 0dBm, so after consulting with Koji, we decided that we will
After implementing these changes, and testing the board with a Marconi on the workbench, I found that the measured power levels (measured with an active FET probe) behave as expected, up till the ERA-5SM immediately prior to the LO (U4 and U6 on the schematic). However, the power after this amplifier (i.e. the input to the on-circuit LO, Minicircuits JMS-1H, which we want to be +17dBm), is only +16dBm. The input to these ERA-5SMs, which are only ~2years old, is -2dBm, so with the typical gain of +20dB, I should have 18dBm at their output. Moreover, increasing the input power to the board from the Marconi doesn't linearly increase the output from the ERA-5SM. Just in case, I replaced one of the ERA-5SMs, but observed the same behaviour, even though the amplifier shouldn't be near saturation (the power upstream of the ERA-5SM does scale linearly).
This needs to be investigated further, so I am leaving the demod board pulled out for now...
The input impedance of the mixer is not constant. As the diode switches, it changes dynamically. Because of this, the waveform of the LO at the mixer input (i.e. the amplifier output) is not sinusoidal. Some of the power goes away to harmonic frequencies. Also, your active probe is calibrated to measure the power across the exact 50Ohm load, which is not in this case. The real confirmation can be done by swapping the mixer with a 50Ohm resistor. But it is too much. Just confirm the power BEFORE the amp is fine. +/-1dB does not change the mixer function much.
Instead, we should measure
- Gain imbalance
of the I/Q output. This can be checked by supplying an RF signal that is 100~1kHz away from the LO frequency and observe I&Q outputs.
29.5 MHz RF Modulation Source
IMC Demodulation Board
I wanted to do a quick check to see if the observed signal levels were in agreement with tests done on the workbench with the Marconi. The mixers used, JMS-1H, have an advertised conversion loss of ~7dB (may be a little higher if we are not driving the LO at +17dBm). The Lissajous ellipse above is consistent with these values. I didn't measure powers with the MC REFL PD plugged into the demod board, but the time series plot above suggest that I should have ~0dBm power in the MC REFL PD signal at 29.5MHz for the strongest flashes (~0.3Vpp IF signal for the strong flashes).
MC Servo Board
Some general remarks
I would think that we want to fix the I/Q orthog inside the demod board by trimming the splitter. Mixing the Q phase signal to the I would otherwise allow coupling of low frequency Q phase junk from HOMs into the MC lock point.
Of course this doesn't matter for the IMC locking as we only use the I phase signal, but
I was a little confused why the In1 Gain had to be as high as +10dB - before the changes to the RF chain, we were using +27dB, and we expect the changes made to have increased the modulation depth by a factor of ~25, so I would have expected the new In1 Gain to be more like 0dB.
While walking by the PSL table, I chanced upon the scope monitoring PMC transmission, and I noticed that the RIN was unusually high (see the scope screenshot below). We don't have the projector on the wall anymore, but it doesn't look like this has shown up in the SLOW monitor channel anyways. Disabling the MC autolocker / closing the PSL shutter had no effect. I walked over to the amplifier setup in 1X2, and noticed that the SMA cable connecting the output of the amplifier to the EOM drive was flaky. By touching the cable a little, I noticed that the trace on the scope appeared normal again. Turning off the 29.5MHz modulation source completely returned the trace to normal.
So I just made a new cable of similar length (with the double heat shrink prescription). The PMC transmission looks normal on the scope now. I also re-aligned the PMC for good measure. So presumably, we were not driving the EOM with the full +27dBm of available power. Now, the In1 Gain on the MC servo board is set to +2dB, and I changed the nominal FSS FAST gain to +18dB. The IMC OLTF now has a UGF of ~165kHz, though the phase margin is only ~27 degrees..
MC Servo Board
Brief Summary: I am currently looking at the acoustic noise around both arms to see if there are any frequencies from machinery around the lab that stand out and to see what we can remove/change. I am using a Bluebird microphone suspended with surgical tubing from the cable trays to isolate it from vibrations. I am also using a preamp and the SR875 spectrum analyzer taking 6 sets of data every 1.5 meters (0 to 200Hz, 200Hz to 400Hz, 400z to 800Hz, 800Hz to 3200Hz, 3.2kHz to 12kHz, 12kHz to 100kHz).
· Attachment 1 is a PSD of the first 3 measurements (from 0 to 12kHz) that I took every 1.5 meters along the x arm with the preamp and spectrum analyzer
· Attachment 2 is a blrms color map of the first 6 sets of data I took (from 2.4m to 9.9m)
· Attachmetn 3 is a picture of the microphone set up with the surgical tubing
Problems that occurred: settings on the preamp made the first set of data I took significantly smaller than the data I took with the 0dB button off and the last problem I had was the spectrum analyzer reading only from -50 to -50 dBVpk
I made a tentative front panel design for the newly installed amplifier box. I used this chassis diagram to place the holes for attaching it. I just made the dimensions match the front of the chassis rather than extending out to the sides since the front panel doesn't need to screw into the rack; the chassis is mounted already with separate brackets. For the connector holes I used a caliper to measure the feedthroughs I'm planning to use and added ~.2 mm to every dimension for clearance, because the front panel designer didn't have their dimensions built in. Please let me know if I should do something else.
The input and coupled output will be SMA connectors since they are only going to the units directly above and below this one. The main output to the EOM is the larger connector with better shielded cables. I also included a hole for a power indicator LED.
EDIT: I added countersinks for 4-40 screws on all the screw clearance holes.
Johannes, if you're going to be putting a front panel order in soon, please include this one.
Also, Steve, I found a caliper in the drawer with a dead battery and the screws to access it were in bad shape- can this be fixed?
I finished designing the PCBs for the VME crate back sides (see attached). The project files live on the DCC now at https://dcc.ligo.org/LIGO-D1700058. I ordered a prototype quantity (9) of the PCB printed and bought the corresponding connectors, all will arrive within the next two weeks. See also attached the front panels for the Acromag DAQ chassis and Lydia's RF amplifier unit (the lone +24V slot confuses me: I don't see a ground connector?). On the Acromag panel, six (3x2) of the DB37 connectors are reserved for VME hardware, two are reserve, and I filled the remaining space with general purpose BNC connectors for whatever comes up.
The amplifier unit should use the three pin dsub connectors (3w3?) that we use on many of the other units for DC power, and preferably go through the back panel. You can leave out the negative pin, since you just need +24 and ground.
There has been a change in the default format for the output of the condor_q command at CIT clusters. This could be problematic for the summary page status monitor, so I have disabled the default behavior in favor of the old one. Specifically, I ran the following commands from the 40m shared account: mkdir -p ~/.condor echo "CONDOR_Q_DASH_BATCH_IS_DEFAULT=False" >> ~/.condor/user_config This should have no effect on the pages themselves.
This is already how it's hooked up. The hole on the from that says +24 V is for an indicator light.
Following the discussion at the meeting today, I wanted to finish up the WFS tuning and then hand over the IFO to Johannes for his loss stuff. So I did the following:
At this point, I figured I would leave the WFS in this state and observe its behaviour overnight. But abruptly, the IMC behaviour changed dramatically. I saw first that the IMC had trouble re-acquiring lock. Moreover, the PC Drive seemed saturated at 10.0V, even when there was no error signal to the MC Servo board. Looking at the MEDM screen, I noticed that the "C1-IOO_MC_SUM_MON" channel had picked up a large (~3V) DC offset, even with In1 and In2 disabled. Moreover, this phenomenon seemed completely correlated with opening/closing the PSL shutter. Johannes and I did some debugging to make sure that this wasn't a sticky button/slider issue, by disconnecting all the cables from the front panel of the servo board - but the behaviour persisted, there seemed to be some integration of the above-mentioned channel as soon as I opened the PSL shutter.
Next, I blocked first the MC REFL PD, and then each of the WFS - turns out, if the light to WFS2 was blocked and the PSL shutter opened, there was no integrating behaviour. But still, locking the MC was impossible. So I suspected that something was wrong with the LO inputs to the WFS Demod Boards. Sure enough, when I disconnected and terminated those outputs of the RF distribution box, I was able to re-lock the MC fine.
I can't explain this bizzare behaviour - why should an internal monitor channel of the MC Servo board integrate anything when the only input to it is the backplane connector (all front panel inputs physically disconnected, In1 and In2 MEDM switches off)? Also, I am not sure how my work on the WFS could have affected any hardware - I did not mess around at the 1X1 rack in the evening, and the light has been incident on the WFS heads for the past few days. The change in modulation depth shouldn't have resulted in the RF power in this chain crossing any sort of damage threshold since the measured power before the changes was at the level of -70dBm, and so should be at most -40dBm now (at the WFS demod board input). The only thing different today was that the digital inputs of the WFS servos were turned on...
So for tonight I am leaving the two outputs of the RF distribution box that serve as the LO for the WFS demod boards terminated, and have also blocked the light to both WFS with beam blocks. The IMC seems to be holding lock steady, PC drive levels look normal...
Unrelated to this work, but I have committed to the svn the updated versions of the mcup and mcdown scripts, to reflect the new gains for the autolocker...
The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am.
The HEPA filter speed at the Variac was turned down to 20V from 40
This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.
Koji, Gautam, Johannes
We quickly checked the situation of the projector in the control room.
- We found that the proejctor was indicating "lamp error".
==> Steve, could you remove the projector from the ceiling and check if it still does not work?
If it still does not work, send it back to the vender. It should be covered by the previous service.
- Zita seemed happy with the DVI output. We tried the dual display configration and VGA and DVI are active right now.
The DVI output (from RADEON something video card) is somewhat strange. We probably need to look into the video display situation.
Turns out the "problem" with WFS2 and the apparent offset accumulation on the IMC Servo board is probably a slow machine problem.
Today, Koji and I looked at the situation a little more closely. This anomalous behaviour of the C1:IOO-MC_SUM channel picking up an offset seems correlated with light being incident on WFS2 head. Placing an ND filter in front of WFS 2 slowed down the rate of accumulation (though it was still present). But we also looked at the in-loop error signal on the IMC board (using the "Out 2" BNC on the front panel), and this didn't seem to show any offset accumulation. Anyways, the ability of the Autolocker doesn't seem to be affected by this change, so I am leaving the WFS servo turned on.
The new demod phases (old +45degrees) and gains (old gains *0.2) have been updated in the SDF table. It remains to see that the WFS loops don't drag the alignment over longer timescales. I will post a more detailed analysis here over the weekend...
Also, we thought it would be nice to have DQ channels for the WFS error signals for analysis of the servo (rather than wait for 30 mins to grab live fine resolution spectra of the error signals with the loop On/Off). So I have added 16 DQ channels [recorded at 2048 Hz] to the c1ioo model (for the I and Q demodulated signal from each quadrant for the 8 quadrants). The "DRATE" for the c1ioo model has increased from ~200 to 410. Comparing to the "DRATE" of c1lsc, which is around 3200, we think this isn't significantly stretching the DAQ abilities of the c1ioo model...
Yikes. Please change the all teh WFS DQ channels sample rates from 2048 down to 512 Hz. I doubt we ever need anything about 180 Hz.
There is sometimes an issue with this: if our digital AA filters are not strong enough, the noise about above 256 Hz can alias into the 0-256 Hz band. We ought to check this quantitatively and make some elog statement about our AA filters. This issue is also seen in DTT when requesting a low frequency spectrum: DTT uses FIR filters which are sometimes not sharp enough to prevent this issue.
Here is a comparison of the error signal spectra after increasing the IMC modulation depth, to the contribution with RF inputs / whitening inputs terminated (which I borrowed from Koji's characterization of the same in Dec 2016, these shouldn't have changed).
Some general observations:
I will update with the in-loop error signal spectra, which should give us some idea of the loop bandwidth.
I will look into lowering the sampling rate, and how much out-of-band power is aliasing into the 0-256 Hz band and update with my findings.
Our new janitor Francisco is started working in IFO room today.
Large film crews are working just out side the north west corner of the lab. They started around ~ 5:30am Do not plan on working late tonight.
ETMX sus damping restored.
C1:PSL-FSS_RMTEMP, C1:PSL-PMC_PMCTRANSPD and C1:PEM-count_temp channels are not reading since Friday
This bulb was blown out on Feb 4, 2017 after 2 months of operation.
ETMX sus damping recovered. PSL enclousure is dusty at 20V rotation speed. Rainy days as outside condition.
Kyle took high quality images of the three sapphire prisms using the microscope @Downs. He analyzed the images to see the radius of the groove.
They all look sufficiently sharp for a 46um steel wire. Thumbs up.
I am curious to see how the wire Q is with grooved sapphires, ungrooved sapphires, grooved ruby, grooved aluminum stand off, and so on.
I've now made a DCC page for the mirror specifications, all revisions should be reflected there.
Over the last couple of days, I've been playing around with Rana's coating optimization code to come up with a coating design that will work for us. The basic idea is a to use MATLAB's particle swarm constrained optimization tool to minimize an error function that is a composite of four penalties:
On the AR side, I only considered 2 and 3. The weighting of these four components were set somewhat arbitrarily, but I seem to be able to get reasonable results so I am going with this for now.
From my first pass at it, the numbers I've been able to get, for 19 layer pairs, are (along with some plots):
(in this picture, the substrate is to the right of layer 38)
(substrate to the right of layer 38)
These numbers are already matching the specs we have on the DCC page currently. I am not sure how much better we can get the specs on the HR side keeping with 19 layer pairs...
All of this data, plus the code used to generate them, is on the gitlab coatings page...
The microscope shipped back to the vendor for credit yesterday.
Using the PDA520 detector on the AS port I tried to get some better estimates for the round-trip loss in both arms. While setting up the measurement I noticed some strange output on the scope I'm using to measure the amount of reflected light.
The interferometer was aligned using the dither scripts for both arms. Then, ITMY was majorly misaligned in pitch AND yaw such that the PD reading did not change anymore. Thus, only light reflected from the XARM was incident of the AS PD. The scope was showing strange oscillations (Channel 2 is the AS PD signal):
For the measurement we compare the DC level of the reflection with the ETM aligned (and the arm locked) vs a misaligned ETM (only ITM reflection). This ringing could be observed in both states, and was qualitatively reproducible with the other arm. It did not show up in the MC or ARM transmission. I found that changing the pitch of the 'active' ITM (=of the arm under investigation) either way by just a couple of ticks made it go away and settle roughly at the lower bound of the oscillation:
In this configuration the PD output follows the mode cleaner transmission (Channel 3 in the screen caps) quite well, but we can't take the differential measurement like this, because it is impossible to align and lock the arm but them misalign the ITM. Moving the respective other ITM for potential secondary beams did not seem to have an obvious effect, although I do suspect a ghost/secondary beam to be the culprit for this. I moved the PDA520 on the optical table but didn't see a change in the ringing amplitude. I do need to check the PD reflection though.
Obviously it will be hard to determine the arm loss this way, but for now I used the averaging function of the scope to get rid of the ringing. What this gave me was:
(16 +/- 9) ppm losses in the x-arm and (-18+/-8) ppm losses in the y-arm
The negative loss obviously makes little sense, and even the x-arm number seems a little too low to be true. I strongly suspect the ringing is responsible and wanted to investigate this further today, but a problem with c1psl came up that shut down all work on this until it is fixed:
I found the PMC unlocked this morning and c1psl (amongst other slow machines) was unresponsive, so I power-cycled them. All except c1psl came back to normal operation. The PMC transmission, as recorded by c1psl, shows that it has been down for several days:
Repeated attempts to reset and/or power-cycle it by Gautam and myself could not bring it back. The fail indicator LED of a single daughter card (the DOUT XVME-212) turns off after reboot, all others stay lit. The sysfail LED on the crate is also on, but according to elog 10015 this is 'normal'. I'm following up that post's elog tree to monitor the startup of c1psl through its system console via a serial connection to find out what is wrong.
The fringes seen on the oscope are mostly likely due to the interference from multiple light beams. If there are laser beams hitting mirrors which are moving, the resultant interference signal could be modulated at several Hertz, if, for example, one of the mirrors had its local damping disabled.
Yes, that was one of the things that I wanted to look into. One thing Gautam and I did that I didn't mention was to reconnect the SRM satellite box and move the optic around a bit, which didn't change anything. Once the c1psl problem is fixed we'll resume with that.
Speaking of which:
Using one of the grey RJ45 to D-Sub cables with an RS232 to USB adapter I was able to capture the startup log of c1psl (using the usb camera windows laptop). I also logged the startup of the "healthy" c1aux, both are attached. c1psl stalls at a point were c1aux starts testing for present vme modules and doesn't continue, however is not strictly hung up, as it still registers to the logger when external login attempts via telnet occur. The telnet client simply reports that the "shell is locked" and exits. It is possible that one of the daughter cards causes this. This seems to happen after iocInit is called by the startup script at /cvs/cds/caltech/target/c1psl/startup.cmd, as it never gets to the next item "coreRelease()". Gautam and I were trying to find out what happends inside iocInit, but it's not clear to us at this point from where it is even called. iocInit.c and compiled binaries exist in several places on the shared drive. However, all belong to R3.14.x epics releases, while the logfile states that the R3.12.2 epics core is used when iocInit is called.
Next we'll interrupt the autoboot procedure and try to work with the machine directly.