I've been suggesting that there may be something wonky with the Seismic Rainbow Striptool on the wall for the last couple of weeks. Here are a few things that were verified today.
I've added the schematic of the RF AM stabilization board to the 40m PSL document tree, after having created a new DCC document for our 40m edits. Pictures of the board before and after modification will also be uploaded here...
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...
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.
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...
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...
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...
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...
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 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
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...
Craig and I have been trying to put together a Simulink diagram of the proposed alternative calibration scheme. Each time I talk the idea over with someone, I convince myself it makes sense, but then I try and explain it to someone else and get more confused. Probably I am not even thinking about this in the right way. So I am putting what I have here for comments/suggestions.
What's the general idea?
Suppose the PSL is locked to the MC cavity, and the AUX laser is locked to the arm cavity (with sufficiently high BW). Then by driving a line in the arm cavity length, and beating the PSL and AUX lasers, we can determine how much we are modulating the arm cavity length in metres by reading out the beat frequency between the two lasers, provided the arm cavity length is precisely known.
So we need:
To be able to sense a 1kHz line being driven at 1e-16 m amplitude, I estimate we need a beat note stability of ~1mHz/rtHz at 1kHz.
Requirements and what we have currently:
On the hardware side of things, we need:
Koji and I briefly looked through the fiber inventory we have yesterday. We have some couplers (one mounted) and short (5m) patch fibers. But I think the fiber infrastructure we have in place currently is adequate - we have the AUX light brought to the PSL table, and there is a spare fiber running the other way if we want to bring the PSL IR to the end as well.
I need to also think about where we can stick the EOM in given physical constraints on the EX table and the beam diameter/aperture of EOM...
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...
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.
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.
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...
Since it would be nice to have the latest version of Matlab, with all its swanky new features (?), available on the control room computers and Optimus, I downloaded Matlab R2016b and activated it with the Caltech Campus license. I installed it into /cvs/cds/caltech/apps/linux64/matlab16b. Specifically, I would like to run the coating optimization code on Optimus, where I can try giving it more stringent convergence criterion to see if it converges to a better spot.
I trust that this way, we don't interfere with any of the rtcds stuff.
If I've done something illegal license-wise or if this is likely to cause havoc, please point me to what is the correct way to do this.
GV 18 Mar 2017: Though I installed this using the campus network license key, this seems to only work on Rossa. If I run it on the other control room machines/Optimus, it throws up a licensing error. I will check with Larry W. as to how to resolve this...
The alignment wasn't disturbed for the photo-taking - I just re-checked that the spot is indeed incident on the MC REFL PD. MC REFL appeared dark because I had placed a physical beam block in the path to avoid accidental PSL shutter opening to send a high power beam during the photo-taking. I removed this beam block, but MC wouldn't lock. I double checked the alignment onto the MC REFL PD, and verified that it was ok.
Walking over to the 1X1, I noticed that the +24V Sorensen that should be pushing 2.9A of current when our new 29.5MHz amplifier is running, was displaying 2.4A. This suggests the amplifier is not being powered. I toggled the power switch at the back and noticed no difference in either the MC locking behaviour or the current draw from the Sorensen.
To avoid driving a possibly un-powered RF amplifier, I turned off the Marconi and the 29.5MHz source. I can't debug this anymore tonight so I'm leaving things in this state so that Lydia can check that her box works fine...
I turned the RF sources back on and opened the PSL shutter. MC REFL was dark on the camera; people were taking pictures of the PD face today so I assume it just needs to be realigned before the mode cleaner can be locked again.
I've been sitting on some data for a while now which I finally got around to plotting. Here is a quick summary:
Attachment #1: I applied a step input to the offset of each of the six WFS loops and observed the step response. The 1/e time constant for all 4 WFS loops is <10s suggesting a bandwidth a little above 0.1Hz. However, the MC2 P and Y loops have a much longer time contant of ~150s. Moreover, it looks like the DC centering of the spot on the QPD isn't great - the upper two quadrants (as per the MEDM screen) have ~3x the cts of the lower pair.
I did not (yet) try increasing the gain of this loop to see if this could be mitigated. I accidentally saved this as a png, I will put up the pdf plot
Attachment #2: This is a comparison of the WFS error signals with the loops engaged (solid lines) vs disabled (dashed lines). Though these measurements were taken at slightly different times, they are consistent with the WFS loop bandwidths being ~0.1Hz.
Attachment #3: Comparison of the spectra of the testpoint channels and their DQ counterparts at the same time which are sampled at 512Hz. It does not look like there is any dramatic aliasing going on, although it is hard to tell what exactly is the order of the digital AA filter implemented by the RCG. Further investigation remains to be done... For reference, here are some notes: T1600059, T1400719
GV 7 March 2017 6pm: It looks like we use RCG v2.9.6, so it should be the latter document that is applicable. I've been going through some directories to try and find the actual C-code where the filter coeffs are defined, but have been unsuccessful so far...
For a few days now, the "code status" page has been telling us that the summary pages are DEAD, even though the pages themselves seemed to be generating plots. I logged into the 40m shared account on the cluster and checked the status of the condor job (with condor_q), and did not find anything odd there. I decided to consult Max, who pointed out that the script that checks the code status (/home/40m/DetectorChar/bin/checkstatus) was looking for a particular string in the log files ("gw_daily_summary"), while the recent change in the default output of condor_q meant that the string actually being written to the log files was "gw_daily_summa". This script has now been modified to look for instances of "gw_daily" instead, and so the code status indicator seems to be working again...
The execution of the summary page scripts has also been moved back to pcdev1 (from pcdev2, where it was moved to temporarily because of some technical problems with pcdev1).
This was still running at ~9.30am today morning, at which point I manually terminated it after confirming with Johannes that it was okay to do so. Judging by the StripTool traces in the control room, the mode cleaner remained locked for most of the night, there should be plenty of usable data...
Note that I re-aligned the Y-arm (to experiment further with photo-taking) at about 9.30am, so the data after this time should be disregarded...
loss map script running on Rossa that moves the beam on ETMX. Yarm was misaligned for this, most recent PIT and YAW settings were saved beforehand. This will take until late at night, I estimate 2-3 am.
Rana suggested including some additional terms to the cost function to penalize high sensitivity to deviations in the layer thickness (L). So the list of terms contributing to the cost function now reads:
I did not include other sensitivity terms, like sensitivity to the refractive index values for the low and high index materials (which are just taken from GWINC).
There is still some arbitrariness in how I chose to weight the relative contributions to the cost function, but after some playing around, I think I have a solution that I think will work. Here are the spectral reflectivity and layer thickness plots for the HR and AR sides respectively.
HR side: for a 1% increase in the thickness of all layers, the transmission changes by 5% @ 1064nm p-pol and 0.5% @ 532nm s and p-pol
AR side: for a 1% change in the thickness of all layers, the transmission changes by <0.5% @ 532nm s and p-pol
(substrate to the right of layer 38)
I've also checked that we need 19 layer pairs to meet the spec requirements, running the code with fewer layer pairs leads to (in particular) large deviations from the target value of 50ppm @ 1064nm p-pol.
Do these look reasonable?
I did a quick measurement of the beam size on the MC REFL PD today morning. I disabled the MC autolocker while this measurement was in progress. The measurement set up was as follows:
This way I was able to get right up to the heat sink - so this is approximately 2cm away from the active area of the PD. I could also measure the beam size in both the horizontal and vertical directions.
The measured and fitted data are:
The beam size is ~0.4mm in diameter, while the active area of the photodiode is 2mm in diameter according to the datasheet. So the beam is ~5x smaller than the active area of the PD. I couldn't find anything in the datasheet about what the damage threshold is in terms of incident optical power, but there is ~100mW on th MC REFL PD when the MC is unlocked, which corresponds to a peak intensity of ~1.7 W / mm^2...
Even though no optics were intentionally touched for this measurement, I quickly verified that the spot is centered on the MC REFL PD by looking at the DC output of the PD, and then re-enabled the autolocker.
There is no internet connectivity on any of the control room machines.
I have been trying to debug by tracing the cabling situation in the rack in the office area, and will update if/when this problem has been resolved. I had last come into the lab on Saturday and there was no problem then. There 40m wireless network servicing the office area seems to work fine.
Koji diagnosed that the NAT router was to blame for this problem. I simply power cycled this router, and now the connectivity has been restored.
It was possible to log into nodus and then to pianosa - and it was also possible to log into the various control room machines once logged into nodus. However, the outward packets seemed to not get transmitted. Anyways, power cycling the NAT Router unit seems to have done the job.
Last night, Valera and I looked into two aspects of the IMC:
I will post a more detailed elog about last night's work, but Valera also thought it might be a good idea to try and improve the mode-matching into the IMC. I couldn't find anything on the wiki/elog about the mode matching situation on the PSL table, so I quickly went over yesterday to measure some lengths. From looking at the MCREFL DC levels when the mode cleaner is locked (~0.37V) and unlocked (~5.7V), the current mode matching efficiency seems to be about 88%, so there is definitely some headroom for improvement.
Here is my cartoon of the situation on the PSL table. All lengths are measured in mm, and I would say correct to +/- 5 mm, so there could be considerable error here...
(L1 : f=+200mm. L2: f=-150mm. L3: f=+400mm)
I extracted the lengths from the edge of the PSL table to IM1 and MC1 from (what I think are) the latest CAD drawings on the DCC. I then put all this into an a la mode script [Attachment #5] - I assumed a waist of 370um at the PMC output mirror, and a waist of 1.78mm at MC1. I neglected the passage through the in-vac Faraday, EOM and BS1 (on the sketch above) and the MC1 substrate. I was able to achieve a theoretical mode-matching efficiency of 1 by just moving the positions of L2 and L3.
Given that there are probably errors of the order 0.5cm in the lengths on the PSL table, and also the in-vacuum distance to MC1, I figured it would be ideal to just move one lens and see if we can improve the efficiency. It looks like it may be more effective to move L2 than L3. The plot on the right shows that the sensitivity is approximately equal to the positioning of L2 and L3. Judging by this plot, looks like w.r.t. the coordinates in this plot, we are somewhere around (0.02,-0.02).
It looks like if we want to do this, moving L2 (f = -150mm) may be the best way to go.
%Create a beamPath object
InpPath = beamPath;
%Add components - for a first pass, ignore Faraday and HWPs, so only
%mirrors and lenses..
The arrangement of filters in the WFS loop filter banks have been altered, Rana will update with details of the motivation behind these changes. Here is how the screen looks now:
I have updated the C1IOO SDF table, and also the mcwfson script to reflect these changes. The latter has been svn committed.
We implemented the plan outlined in the previous elog. The visibility (Pmax-Pmin)/(Pmax+Pmin) calculated with the MC REFL PD levels with the MC locked/unlocked is now ~96% (up from 88%). The MC REFL DC level in lock is now ~0.12V (compared to 0.4V). Assuming a modulation depth of 0.1 @ 29.5MHz, about 25% of this (i.e. 0.03V) is from sideband light.
The procedure followed was (see sketch in previous elog for various optic labels):
We could probably tweak the fine positioning of L2 and L3 and improve the efficiency a little more, but the primary objective here was to see if there was any effect on the large common mode offset on the WFS demodulated "SUM" output. Unfortunately, we saw no effect.
Here are two photos of the relevant section of the PSL table before (left) and after (right) our work there:
Motivation: see this elog
I was fiddling around for a few days trying to implement the method outlined in this paper to null this offset - I will post a separate elog about my efforts but Valera pointed out that we could try injecting an AF modulation at the IN2 input of the MC Servo Board. Last night, we hooked up an SR function generator (f = 312Hz, A = 0.01Vpp, IN2 gain = -5dB) to the unused BNC IN2 input of the MC Servo board. To avoid any additional offsets from the AO path during this measurement, I disconnected the LEMO cable (it is labelled).
We looked at the spectrum of the MC transmission around 312Hz and also 2*f = 624Hz. As a result of this modulation, we expect in the transmitted power, dP/P, a 2f term with amplitude ~(X_mod/X_0)^2 and a term at f with amplitude ~(X_offset * X_mod / X_0^2) - I may have missed out some numerical factors of order 1. So the latter should vanish if the offset at the error point is truly zero and the lock-point is the center of the resonance. Last night, we found that an offset in the range of -0.25 V to -0.19 V nulled this peak in the DTT spectrum. Today, the number was -0.05V. So the true offset seems to vary from lock to lock. Here are spectra around f=312Hz for a few different values of the offset slider (the center of the resonance seems to be -0.05V on the MEDM slider at this time).
Do these numbers make sense? Some time ago, I had pulled out the MC Servo board to find out what exactly is going on at this offset summing point. The MEDM slider goes from -10V to 10V, and by measuring the voltage at TP5 (see schematic below), I found that there is a 1/40 scaling factor between what is actually applied and the number on the MEDM slider (so for example, the numbers in the legend in the above plot have to be divided by 40). I've modified the MC Servo Board MEDM screen to reflect this. When I had pulled the board out, I noticed that in addition to the offset voltage applied via the backplane connector, there was also a potentiometer (R50 in the schematic below). I had nulled the voltage at TP5 using this potentiometer, but I guess drifts of ~5mV are possible.
Discussion on calibration of offset slider in Hz/V:
I've yet to do a rigorous calibration of this slider into Hz, but looking at the spectrum of the transmitted intensity at 2f, we estimated the coefficient (X_mod/X_0) ~ 3e-3 for an offset of 0.2V. dP/P ~1 when the applied modulation equals the linewidth of the cavity, which is 3.6kHz. So 0.2V of offset slider corresponds to ~ 10Hz frequency offset. In other words, I estimate the slider calibration to be 50Hz/V. So with the full range of +/- 10V, we should be able to scan ~1kHz of frequency offset. What does this imply about the variation of the offset slider value that removes the peak at 1f between locks? As mentioned above, this variation is ~0.2V over a day - with the calibration mentioned above, this corresponds to a change in cavity length of ~10um, which seems reasonable to me...
So how did all of this tie in with WFS SUM offsets? We did the following:
I neglected to screenshot the StripTool from the times we were doing these trials but I have the times, I will pull up some dataviewer plots and upload them here tomorrow...
I've taken a bunch of transfer function measurements from the MC ASC PIT and YAW channels to the WFS error signals using the same set of DTT templates Koji used while characterizing the WFS loops a couple of months ago, before the IMC RF changes. Analysis is underway and I will post the results here shortly...
As an aside, Rana had added 10dB and 20dB gains to all of the WFS filter banks yesterday. I tried engaging the 10dB gains on the two MC2_TRANS PD loops, and this did not seem to induce any instability. I stepped both loops and saw that as expected, the 1/e times for both of these loops is about 45 seconds now (compared to ~150 seconds at the nominal gain). These have been running all day today, and the IMC seems well behaved, so I am going to leave these on for now... Jacking up the gain on the MC2_TRANS_QPD loops by 20dB induced instability - same story for the 4 WFS loops with 10dB additional gain...
Thanks to Koji's nice MATLAB script using DttData functions, I was able to quickly analyze the TF data. Essentially, this measurement was a repetition of what was done here. The difference is that the modulation depth has been increased by ~25x compared to that measurement from December 2016. Here are the measured TFs (before accounting for the 1/f^2 normalization) for the various quadrants and the PIT/YAW channels:
The plots above are just to illustrate that the measurement was clean between the band over which the averaging will be done to compute the TF amplitude - i.e. 7-15Hz. The full summary of TF amplitudes, standard deviations, and the sensing matrix in the style of the referenced elog (the actual excel spreadsheet is Attachment #4, minus some of the graphics Koji had on his excel sheet):
Inverting those matrices, we get the matrices that diagonalize the sensor-actuator chain:
I will try implementing these matrices tomorrow and take a look at the step responses of the loops - the idea is that perhaps the system wasn't optimally diagonalized before and perhaps we can now improve the bandwidths of all the loops.
I've reduced the gains of the damping on all 3 MC SUS by a factor of 3 for overnight observation as part of the ongoing feedforward noise cancellation investigations. I will return them to the nominal values tomorrow morning.
I've restored the damping loop gains to their nominal values. Analysis of the coherence between MCL and seismometer channels under this reduced gain setting is underway, results to follow.
I repeated this measurement as follows:
Here is a calibrated MC_F spectrum:
RXA: I've added this plot of the free-running noise of the Lightwave NPRO which is probably similar to our Innolight Mephisto. Seems like the laser is quieter than MC_F everywhere below 100 Hz.
On Wednesday at the meeting, we were discussing why we aren't able to achieve more seismic feedforward subtraction in MCL. We spent some time thinking about this yesterday, and this elog is meant to be a summary of the stuff we tried.
The seismometer spectra look similar enough to be explained by time of day variations, so perhaps the culprit is MC1. The ambient MCL spectrum is almost an order of magnitude higher above 4Hz now, with the nominal damping loop gains, as compared to back in January. I think the damping loops on MC1 need to be tweaked.
The C1IOO frontend machine that resides in 1X1/1X2 has 2 ADCs, ADC0 and ADC1. The latter has 28 out of 32 channels unused at the moment, so I decided to use this for setting up fast channels for the PMC DAQ. On the RTCDS side of things, the PSL namespace block lives in the C1ALS model. I made the following modifications to it:
The PSL namespace block in C1ALS looks like this now:
I then tried hooking up the DAQ signals from the PMC servo board to the ADC via the 1U generic ADC interface chassis in 1X2 - this has 4pin LEMO inputs corresponding to 2 differential input channels. I used J6 (corresponding to ADC channels 10 and 11) for the PMC_ERR and PMC_CTRL respectively. I was a little confused about the status of the 4 pin LEMO output on the front panel of the PMC servo board. According to the DCC page for the modified 40m servo board, the DAQ outputs are wired to the backplane connector instead of the 4 pin LEMO. But looking at photographs on the same DCC page, there are wires soldered on the rear-side of the PCB from the 4-pin LEMO to the backplane connector. Also, I believe the measurements made by Rana in the preceeding elog were made via the front panel LEMO. In any case, I decided to use the single pin LEMO monitor points on the front panel as a preliminary test. The uncalibrated spectra with ADC terminated, IMC unlocked and IMC locked look like:
So it looks like at the very least, we want to add some gain to the AD620 instrumentation amplifiers to better match the input range of the ADC. We also want to make the PZT voltage monitor path AC coupled. My plan then is the following:
I will update with a circuit diagram with proposed changes shortly.
The PCB layout is such that I think using components with leads is easier rather than SMD components.
If this sounds like a reasonable plan, I will pull out the servo card from the eurocrate and implement these changes today evening...
As part of the ongoing effort to try and calibrate the PMC DAQ channels into physical units, I tried to get a calibration for the PSL NPRO PZT actuator gain. In order to do this, I selected "Blank" on the PMC servo MEDM screen such that there was no feedback signal to the PMC PZT for length control. Then I used the summing box right before the PSL PZT to inject a ~1Hz triangular wave, 4Vpp. This was sufficient to sweep the NPRO frequency over 70MHz such that both sidebands and the carrier go through resonances in the PMC cavity. I then simultaneously monitored the applied triangular wave voltage and the PMC error signal (using the single pin LEMO connector on the front panel) on an oscilloscope. Analysis is underway, but a quick look at one measurement suggests a PZT actuator gain of ~1.44MHz/V, which is close to what we expect for the Innolight NPROs. The idea is to use this calibration to convert the DQ channels into physical units.
Details + plots + error analysis to follow...
When I came in this morning, Steve had re-locked the PMC and IMC - but I could see a ~1Hz intensity fluctuation on the PMC REFL video monitor. I unlocked the PMC and tried to re-lock it, but couldn't using the usual prescription of turning the servo gain down and moving the DC bias slider around. I checked the status of the slow machines - all were responding to pings and could be telnet'ed into, so that didn't seem to be the problem. In the past, this sort of behaviour was characteristic of the infamous "sticky slider" problem - so I simply burt-restored c1psl using a snapshot from 29 March, after which I could easily re-lock the PMC. The transmitted light level looked normal on the scope on the PSL table, and the PMC REFL video monitor also look normal now.
By sweeping the laser frequency and looking at the PMC PDH error signal, I have determined the 2W Mephisto Innolight PZT actuator gain to be 1.47 +/- 0.04 MHz/V.
An example of the data used to calculate the actuator gain (left), and the spread of the calculated actuator gain (right - error bars calculated assuming 5e-4 s uncertainty in the sideband zero-crossing interval, and using the error in the slope of the linear fit to the sweep voltage):
This will now allow calibration of the PMC DAQ channels into Hz.
GV 4 April - The y-axis of the lower plot in Attachment #1 has mis-labelled units. It should be [V], not [MHz/V].
I made some changes to the DAQ path on the PMC servo board, as per the plan posted earlier in this thread. Summary of changes:
Details + photos + calibration of DAQ channels to follow. The PMC and IMC both seem to remain stably locked after this work.
We spent some time trying to get the noise-budgeting code running today. I guess eventually we want this to be usable on the workstations so we cloned the git repo into /ligo/svncommon. The main objective was to see if we had all the dependencies for getting this code running already installed. The way Evan has set the code up is with a bunch of dictionaries for each of the noise curves we are interested in - so we just commented out everything that required real IFO data. We also commented out all the gwpy stuff, since (if I remember right) we want to be using nds2 to get the data.
Running the code with just the gwinc curves produces the plots it is supposed to, so it looks like we have all the dependencies required. It now remains to integrate actual IFO data, I will try and set up the infrastructure for this using the archived frame data from the 2016 DRFPMI locks..
Koji and I have been going over these calculations again before we send a list of revised requirements to Ramin. I've uploaded v3 of the specs to the DCC page. Here is a summary of important changes.
If there are no objections, I would like to send this version of the specs to Ramin and get his feedback. Specifically, I have assumed values for the refractive indices of SiO2 and Ta2O5 from google, Garilynn tells me that we should get these values from Ramin. Then we can run the code again if necessary, but these MC studies already suggest this coating design is robust to small changes in assumed values of the parameters...
As discussed at the Wednesday meeting last week, I tried moving the demodulation of the PMC error signal off the PMC servo board, by using some minicircuits components. This is just a quick summary elog, more details to follow tomorrow.
During the course of this work, I noticed that there was a 35.5MHz line (at ~-55dBm) in the 4-pin LEMO DAQ outputs even when all other inputs to the servo board were terminated. So it seems like this pickup is not coming from the RFPD or demod path. The LO board has a shield enclosure similar to what we have on the LSC demod boards, but perhaps this shield does not enclose the full RF path, and there is some residual pickup between the two cards in close proximity in the Eurocrate?
On the bright side, with this demod setup, the higher harmonic peaks seem to be significantly suppressed.
In particular, the 3x35.5 MHz peak which was very prominent when I looked at these spectra with the nominal demod setup, seems to be much suppressed.
I'm leaving the PMC servo in this configuration (off servo board demodulation using minicircuits parts) overnight.
Here is a more detailed comparison of the spectra of the signals at the front panel DAQ LEMO output, measured with the Agilent analyzer. I've left the scale linear, it looks like when the demodulation is done on the servo board, the 1x, 3x and 5x harmonics of the 35.5MHz modulation are clearly visible. I also plut in a plot of the spectra when both the PD and LO inputs to the servo board are terminated (and so the PMC is unlocked), but with the HV In and OUT of the servo board still connected. In this case, the higher harmonics vanish, but a 35.5MHz peak of ~-50dBm remains. Since this is present with no input to the servo board, this must be direct pickup from the nearby LO board?
In any case, it looks like many of the harmonics that are present with the nominal demod setup either vanish or are much more suppressed when the error signal demodulation is done off the servo board .
Further down the signal chain, I had noticed sometime last week that the ADC signals for the PMC DAQ channels I set up seemed to saturate around 4000 counts. Rana mentioned that the ADC interface box with LEMO connectors on the front is powered with +/-5V. Valera and co. had simply increased the suppy voltage sometime ago to get around this problem, so I did something similar, and increased the supply voltage to +/- 15V. I then confirmed that the ADC doesn't get saturated by driving the input with a +/-5V signal. So now the amplified AD620 signals from the PMC servo board are better matched to the ADC range.
Here is an uncalibrated spectrum (taken with IMC locked), compared to the current ADC noise and signal levels before the AD620s were given gain.
I now need to think a little about what exactly the control scheme would be if the PMC is used as a reference for the IMC over some frequency range...
Quick entry, details to follow in the AM tomorrow.
Here are the details:
The updated schematic with changes made, along with some pictures, have been uploaded to the DCC page...
Quick entry, details to follow in the AM tomorrow.