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.
I used a one hour stretch of data from last night to look at coherence between the PMC control signal and MCL, to see if the former can be used as a witness channel in some frequency band for MCL stabilization. Here is a plot of the predicted subtraction and coherence, made using EricQs pynoisesub code. I had thought about adopting the greedy channel ranking algorithm that Eric has been developing for noise subtraction in site data, but since I am just considering 3 witness channels, I figured this straight up comparison between different sets of witness channels was adequate. Looks like we get some additional coherence with MCL by adding the PMC control signal to the list of witness channels, there is about a factor of a few improvement in in the 1-2Hz band...
I looked through the lab area to do a fast photodiode inventory check, as we may need to buy some for the higher order mode spectroscopy SURF project. I looked on the following optical tables: ETMY, ITMY, BS, AS, PSL, SP, ITMX, Jenne laser table, and ETMX, as well as the photodiode cabinet, and could only find two 1611s. Here is a summary of the inventory:
I have not yet checked if these photodiodes are in working order.
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...
Since we'd like to get back to DRSE locking, I tried locking the DRMI tonight. I did the following:
GV 26 April 2017, 3pm: Forgot to note yesterday that I re-connected the suspect Satellite box, which has been connected to the SRM signal chain, back to the SRM suspension. I did not see any instances of glitching during my work last night. Also added pictures showing shifted spots on ITMs when PRC is locked relative to when arms are locked...
I got a couple of ~30min long DRMI lock stretches today. The settings I used are essentially the same as what I had back in November. Though we have since made some changes to the IMC RF signal chain, I guess it is not unreasonable that the LSC Demod phases that worked then work now as well.
In the lock stretches, I did the following:
On the side, I'm also looking at whether the PRC angular feedforward filters, last trained in October 2016, remain valid. Even post midnight, I am unable to lock the DRMI without turning on the FF, and looking at the POP QPD PIT and YAW signal spectra with the FF on vs FF off, there is definitely some improvement in the 1-4Hz band (plot to follow), question is whether we can do better and hence improve the DRMI duty cycle/ make the lock acquisition easier. To this end, I centered the beam on the POP QPD after locking and dither aligning the PRC on carrier, and have taken some data to look at.
So, much data analysis to follow - the idea is to put together a DRMI noise budget with Evan's NB code. For now, here are the uncalibrated control signal spectra.
I took a closer look at the POP QPD/ PRC angular feedforward situation yesterday. I thought it would be useful to have a POP QPD MEDM screen. Looking at the PIT and YAW channel filter modules, the anti-whitening filters seemed different from what we have for other channels that are connected to the Pentek interface board (e.g. MCL). So I copied over the 150:15 (z:p) filter, and also turned on a 60Hz comb. The LSC offsets script does not set the dark offsets for this QPD, so I manually put in the dark offsets for the PIT, YAW and SUM channels as well. For the locking, I first locked the arms on IR an dither aligned them. Then I locked the PRMI on carrier, ran the PRC dither alignment, and went over to the ITMX pickoff table and centered the beam on the QPD by making the PIT and YAW channel timeseries oscillate around approximately zero.
After these tweaks, I collected ~40mins of data with the angular FF OFF/ON. I did not DC couple the ITM Oplev servos, but Eric tells me that this did not make a difference to the achievable subtraction in the past. Here is the frequency domain multicoherence analysis - I used the BS_X and BS_Y seismometer channels as witnesses. I've also put a plot with what the raw FF filter coefficients look like (no fitting yet).
Looks like we can do better for both DOFs - it even seems like we are injecting noise with the current FF filters in some bands, perhaps we can do a better job of rolling off the filters outside the band of interest. Eric and I were discussing MATLAB's "reduce" routine for this purpose, I will play around with it and see if I get a better fit.
Unfortunately, I encountered a strange error when trying to pull data with nds2 today, it kept complaining RuntimeError: Too many channels or too much data requested. even though I have pulled longer stretches of data for more channels with 16k sampling rate as recently as last week. Shorter duration requests (<600 seconds) seemed to work fine though... So I had to use cds.getdata to pull the data, and they're much too large to attach. Has anyone else encountered a similar error?
The mystery of the spots on the ITMs when the PRC is locked on carrier remains - after talking this over with Koji, we figured that even with the carrier resonant, the spot will be much dimmer than the spots when the arms are locked, but what I see on the cameras is still a pretty beefy spot. The real cavity mode is actually visible where it should be (I marked the locations of the spots with arms well-aligned with a marker on the monitors), as given away by some twinkling that is visible only when the cavity is locked. But what ghost beam is so intense it looks almost as bright as when the arm is locked?
GV 10pm 28 April 2017: Turns out this is the spot from the single bounce off the ETM transmitting back through the ITM and hitting the suspension cage (hence the bright spot). Johannes and I confirmed by moving the ETM, the spot moved with it. I just never paid attention to this spot before.
For the traces I posted, I had not turned on the whitening for the SRCL sensing PD (REFL55). However, I took a spectrum on a subsequent lock, with the analog whitening + digital dewhitening turned on for all 3 PDs (AS55, REFL11 and REFL55), and the HF part of the SRCL spectrum still looked anomalous. I'm putting together the detailed NB, but here's a comparison between the signals from the 3 RFPDs with the PSL shutter closed (but whitening engaged, and with the analog gains at the same values as used during the locking).
To convert the y-axis into m/rtHz, I used data from a sensing matrix measurement I took yesterday night during a DRMI lock - I turned on lines between 300 Hz and 325 Hz for the 3DOFs for ~5 minutes, downloaded the RFPD error signal data and did the demodulation. I used numbers from this elog to convert the actuator drive from cts to m. The final numbers I used were:
MICH (AS55_Q): 8.706 * 10^11 cts/m
PRCL (REFL11_I): 2.757 * 10^12 cts/m
SRCL (REFL55_I): 1.995 * 10^10 cts/m
So it looks like there may be something weird going on with the REFL55 signal chain. Looking at the LSC rack (and also suggested by an elog search), it looks like the demodulation is done by a demod board labelled "POP55" - moreover, the demodulated outputs are taken not from the regular output ports on this board, but from the "MON" ports on the front panel.
one of these signals does not look like the others: explanation?
I forgot we had done this last year already, but we updated the control room network switch labels and double checked all the connections. Here is the status of the connections and labels as of today:
There are a few minor changes w.r.t. labeling and port numbers compared to the Dec 2015 entry. But it looks like there was no IP clash between Rossa and anything (which was one of the motivations behind embarking on this cleanup). We confirmed by detatching the cable at the PC end of Rossa, and noticed the break in the ping signals. Plugging the cable back in returned the pings. Because Rossa is currently un-bootable, I couldn't check the MAC address.
We also confirmed all of this by using the web browser interface for the switch (IP = 192.168.113.249).
I've been playing around with Evan's NB code trying to put together a noise budget for the data collected during the DRMI locks last week. Here is what I have so far.
Attachment #1: Sensing matrix measurement.
Attachment #2: MICH OLTF measurement vs model
Attachment #3: Noise budget
I think I did the various conversions/calibrations/loop algebra correctly, but I may have overlooked something. Now that the framework for doing this is somewhat set up, I will try and put together analogous NBs for PRCL and SRCL.
GV 22 August 2017: Attachment #4 is the summary of my demod board efficiency investigations, useful for converting sensing measurement numbers from cts/m to W/m.
In order to do so, I took a swept sine measurement with a few points between 50 Hz and 500 Hz. The transfer function between C1:LSC-MICH_OUT_DQ and the Oplev Servo Output point (e.g. C1:SUS-BS_OL_PIT_OUT etc) was measured. I played around with the excitation amplitude till I got coherence > 0.9 for the TF measurement, while making sure I wasn't driving the Oplev error point too hard that side-lobes began to show up in the MICH control signal spectrum.
I was also looking at the Oplev servo shapes and noticed that they are different for the ITMs and the BS (Attachment #1). Specifically, for the ITM Oplevs, an "ELP15" is used to do the roll-off while an "ELP35" is employed in the BS servo (though an ELP35 also exists in the ITM Oplev filter banks). I got lost in an elog search for when these were tuned, but I guess the principles outlined in this elog still hold and can serve as a guideline for Oplev loop tweaking.
Coil driver noise estimation to follow
I think the most important next two items to budget are the optical lever noise, and the coil driver noise. The coil driver noise is dominated at the moment by the DAC noise since we're operating with the dewhitening filters turned off.
GV 10 May 12:30pm: I've uploaded another copy of the NB (Attachment #3) with the contributions from the ITMs and BS separated. Looks like below 100Hz, the BS coupling dominates, while the hump/plateau around 350Hz is coming from ITMX.
The MCautolocker had stalled - there were no additional lines to the logfile after 12:17pm (~20mins ago). Normally, it suffices to ssh into megatron and run sudo initctl restart MCautolocker - but it seems that there was no running initctl instance of this, so I had to run sudo initctl start MCautolocker. The FSS Slow control initctl process also seemed to have been terminated, so I ran sudo initctl start FSSslowPy.
I first shutdown the SRM watchdog, noted cabling between these boards and also the AI board as well as output to Sat. Box. I also needed to shutdown the MC2 watchdog as I had to remove the DAC output to MC2 in order to remove the SRM Dewhitening board from the rack. This connection has been restored, MC locks fine now.
I've added marked-up schematics + high-res photographs of the SRM coil driver board and dewhitening board to the 40m DCC Document tree (D1700217 and D1700218).
In the attached marked-up schematics, I've also added the proposed changes which Rana and I discussed earlier today. For the thick-film -> thin-film resistor switching, I will try and make a quick LISO model to see if we can get away with replacing just a few rather than re-stuff the whole board.
Another change I think should be made, but I forgot to include on the markups: On the dewhitening board, we should probably replace the decoupling capacitors C41 and C52 with equivalent value electrolytic caps (they are currently tantalum caps which I think are susceptible to fail by shorting input to output).
I've made the LISO models for the dewhitening board and coil driver boards I pulled out.
Attached is a plot of the current noise in the current configuration (i.e. dewhitening board just has a gain x3 stage, and then propagated through the coil driver path), with the top 3 noise contributions: The op-amps (op3 and op5) are the LT1125s on the coil driver board in the bias path, while "R12" is the Johnson noise from the 1k input resistace to the OP27 in the signal path.
Assuming the OSEMs have an actuation gain of 0.016 N/A (so 0.064 N/A for 4 OSEMs), the current noise of ~1e-10 A/rtHz translates to a displacement noise of ~3e-15m/rtHz at ~100Hz (assuming a mirror mass of 0.25kg).
I have NOT included the noise from the LM6321 current buffers as I couldn't find anything about their noise characteristics in the datasheet. LISO files used to generate this plot are attached.
I first set the bias sliders to 0 on the MEDM screen (after checking that the nominal values were stored), then shut down the watchdogs, and then pulled out the boards for inspection + photo-taking.