I have modified the LSC trigger matrix screen, as well as the LSC overview screen, to reflect the modifications to the model from yesterday.
Also, I decided that we probably won't ever want to trigger the zero crossing on the Q phase signals of REFL. Instead, we may want to try it out with the single arms, so the zero crossing selection matrix is now REFL11I, REFL55I, POX11I, POY11I, in that order.
EDIT, JCD, 17Feb2015: Updated loop diagram and calculation: http://22.214.171.124:8080/40m/11043
Okay, Koji and I talked (after he talked to Rana), and I re-looked at the original cartoon from when Rana and I were thinking about this the other day.
The original idea was to be able to actuate on the MC frequency (using REFL as the sensor), without affecting the ALS loop. Since actuating on the MC will move the PSL frequency around, we need to tell the ALS error signal how much the PSL moved in order to subtract away this effect. (In reality, it doesn't matter if we're actuating on the MC or the ETMs, but it's easier for me to think about this way around). This means that we want to be able to actuate from point 10 in the diagram, and not feel anything at point 4 in the diagram (diagram from http://126.96.36.199:8080/40m/11011)
This is the same as saying that we wanted the green trace in http://188.8.131.52:8080/40m/11009 to be zero.
So. What is the total TF from 10 to 4?
So, to set this equal to zero (ALS is immune to any REFL loop actuation), we need .
Next up, we want to see what this means for the closed loop gain of the whole system. For simplicity, let's let , where * can be either REFL or ALS.
Recall that the closed loop gain of the system (from point 1 to point 2) is
, so if we let and simplify, we get
This seems a little scary, in that maybe we have to be careful about keeping the system stable. Hmmmm. Note to self: more brain energy here.
Also, this means that I cannot explain why the filter wasn't working last night, with the guess of a complex pole pair at 1Hz for the MC actuator. The ALS plant has a cavity pole at ~80kHz, so for our purposes is totally flat. The only other thing that comes to mind is the delays that exist because the ALS signals have to hop from computer to computer. But, as Rana points out, this isn't really all that much phase delay below 100Hz where we want the cancellation to be awesome.
I propose that we just measure and vectfit the transfer function that we need, since that seems less time consuming than iteratively tweaking and checking.
Also, I just now looked at the wiki, and the MC2 suspension resonance for pos is at 0.97Hz, although I don't suspect that that will have changed anything significantly above a few Hz. Maybe it makes the cancellation right near 1Hz a little worse, but not well above the resonance.
I've fixed the gpib scripts for the SR785 and AG4395A to output data in the same format as expected by older scripts when called by them. In addition, there are now some easier modes of operation through the measurement scripts SRmeasure and AGmeasure. These are on the $PATH for the main control room machines, and live in scripts/general/netgpib
Case 1: I manually set up a measurement on the analyzer, and just want to download / plot the data.
Make sure you have a yellow prologix box plugged in, and can ping the address it is labeled with. (i.e. 'vanna'). Then, in the directory you want to save the data, run:
SRmeasure -i vanna -f mydata --getdata --plot
This saves mydata_(datetime).txt and mydata_(datetime).pdf in the current directory.
In all cases, AGmeasure has the identical syntax. If the GPIB address is something other than 10, specifiy it with -a, but this is rarely the case.
Case 2: I want to remotely specify a measurement
Rather than a series of command line arguments, which may get lost to the mists of time, I've set the scripts up to use parameter files that serve as arguments to the scripts.
Get the templates for spectrum and TF measurements in your current directory by running
Set the parameters with your text editor of choice, such as frequency span, filename output, whether to create a plot or not, then run the measurement:
Case 3: I want to compare my data with previous measurements
In the template parameter files, there is an option 'plotRefs', that will automatically plot the data from files whose filenames start with the same string as the current measurement.
If, in the "#" commented out header of the data file, there is a line that contains "memo:" or "timestamp:", it will include the text that follows in the plot legend.
There are also methods to remotely trigger an already configured measurement, or remotely reset an unresponsive instrument. Options can be perused by looking at the help in SRmeasure -h
I've tested, debugged, and used them for a bit, but wrinkles may remain. They've been svn40m committed, and I also set up a separate git repository for them at github.com/e-q/netgpibdata
We woke up the PDFR measurement setup that has been sleeping since summer. We ran a check for the laser module and the multiplexer module. We tried setting things up for measuring frequency response of AS55.
We could not repeat Nichin's measurements because the gpib scripts are outdated and need to be revised.
PDFR diode laser was shutdown after this job.
The fibers around the PSL table were shielded to avoid any tampering.
The goals are:
- When the REFL path is dead (e.g. S_REFL = 0), the system goes back to the ordinary ALS loop. => True (Good)
- When the REFL path is working, the system becomes insensityve to the ALS loop
(i.e. The ALS loop is inactivated without turning off the loop.) => True when (...) = 0
Are they correct?
Then I just repeat the same question as yesterday:
S is a constant, and Ps are cavity poles. So, approximately to say, (...) = 0 is realized by making D = 1/G_REFL.
In fact, if we tap the D-path before the G_REFL, we remove this G_REFL from (...). (=simpler)
But then, this means that the method is rather cancellation between the error signals than
cancellation between the actuation. Is this intuitively reasonable? Or my goal above is wrong?
I have calculated the response of this new 2.5 loop system.
The first attachment is my block diagram of the system. In the bottom left corner are the one-hop responses from each green-colored point to the next. I use the same matrix formalism that we use for Optickle, which Rana described in the loop-ology context in http://nodus.ligo.caltech.edu:8080/40m/10899.
In the bottom right corner is the closed loop response of the whole system.
Also attached is a zipped version of the mathematica notebook used to do the calculation.
EDIT, JCD, 17Feb2015: Updated loop diagram and calculation: http://184.108.40.206:8080/40m/11043
I have been able to recover the ability to sit at zero CARM offset while the PRMI is locked on RELF33 and CARM/DARM are on ALS, effectively indefinitely. However, I feel like the transmon QPDs are not behaving ideally, because the reported arm powers freqently go negative as the interferometer is "buzzing" through resonance, so I'm not sure how useful they'll be as normalizing signals for REFL11. I tried tweaking the DARM offset to help the buildup, since ALS is only roughly centered on zero for both CARM and DARM, but didn't have much luck.
Turning off the whitening on the QPD segments seems to make everything saturate, so some thinking with daytime brain is in order.
How I got there:
It turns out triggering is more important than the phase margin story I had been telling myself. Also, I lost a lot of time to needing demod angle change in REFL33. Maybe I somehow caused this when I was all up on the LSC rack today?
We have previously put TRX and TRY triggering elements into the PRCL and MICH rows, to guard against temporary POP22 dips, because if arm powers are greater than 1, power recylcing is happening, so we should keep the loops engaged. However, since TRX and TRY are going negative when we buzz back and forth through the resonsnace, the trigger row sums to a negative value, and the PRMI loops give up.
Instead, we can used the fortuitously unwhitened POPDC, which can serve the same function, and does not have the tendancy to go negative. Once I enabled this, I was able to just sit there as the IFO angrily buzzed at me.
Here are my PRMI settings
REFL33 - Rotation 140.2 Degrees, -89.794 measured diff
PRCL = 1 x REFL33 I; G = -0.03; Acquire FMs 4,5; Trigger FMs 2, 9; Limit: 15k ; Acutate 1 x PRM
MICH = 1 x REFL33 Q, G= 3.0, Acquire FMs 4,5,8; Trigger FM 2, 3; Limit: 30k; Actuate -0.2625 x PRM + 0.5 x BS
Triggers = 1 x POP22 I + 0.1 * POPDC, 50 up 5 down
Just for kicks, here's a video of the buzzing as experienced in the control room
With the Y Arm locked, we checked that we indeed can get loop decoupling using this technique.
The guess filter that we plugged in is a complex pole pair at 1 Hz. We guessed that the DC gain should be ~4.5 nm count. We then converted this number into Hz and then into deg(?) using some of Jenne's secret numbers. Then after measuring, we had to increase this number by 14.3 dB to an overall filter module gain of +9.3.
The RED trace is the usual 'open loop gain' measurement we make, but this time just on the LSC-MC path (which is the POY11_I -> ETMY path).
The BLUE trace is the TF between the ALS-Y phase tracker output and the FF cancellation signal. We want this to be equal ideally.
The GREEN trace is after the summing point of the ALS and the FF. So this would go to zero when the cancellation is perfect.
So, not bad for a first try. Looks like its good at DC and worse near the red loop UGF. It doesn't change much if I turn off the ALS loop (which I was running with ~10-15x lower than nominal gain just to keep it out of the picture). We need Jenne to think about the loop algebra a little more and give us our next filter shape iteration and then we should be good.
The nonlinearity in the LSC detection chain (cf T050268) comes from the photodetector and not the demod board. The demod board has low pass or band pass filters which Suresh installed a long time ago (we should check out what's in REFL33 demod board).
Inside the photodetector the nonlinearity comes about because of photodiode bias modulation (aka the Grote effect) and slew rate limited distortion in the MAX4107 preamp.
In order to try out the new locking scheme tonight, I have modified the LSC model. Screens have not yet been made.
It's a bit of a special case, so you must use the appropriate filter banks:
CARM filter bank should be used for ALS lock. MC filter bank should be used for the REFL1f signal.
The output of the MC filter bank is fed to a new filter bank (C1:LSC-MC_CTRL_FF). The output of this new filter bank is summed with the error point of the CARM filter bank (after the CARM triggered switch).
The MC triggering situation is now a little more sophisticated than it was. The old trigger is still there (which will be used for something like indicating when the REFL DC has dipped). That trigger is now AND-ed with a new zero crossing trigger, to make the final trigger decision. For the zero crossing triggering, there is a small matrix (C1:LSC-ZERO_CROSS_MTRX) to choose what REFL 1f signal you'd like to use (in order, REFL11I, REFL11Q, REFL55I, REFL55Q). The absolute value of this is compared to a threshold, which is set with the epics value C1:LSC-ZERO_CROSS_THRESH. So, if the absolute value of your chosen RF signal is lower than the threshold, this outputs a 1, which is AND-ed by the usual schmidt trigger.
At this moment, the input and output switches of the new filter bank are off, and the gain is set to zero. Also, the zero crossing selection matrix is all zeros, and the threshold is set to 1e9, so it is always triggered, which means that effectively MC filter bank just has it's usual, old triggering situation.
I have moved the optical fiber module for FOL to the PSL table. It is setup on the optical table right now for testing.
Once tests are done, the box will move to the rack inside the PSL enclosure.
While doing any beat note alignment, please watch out for the loose fibers at the north side of the PSL enclosure until they are sheilded securely (probably tomorrow morning).
33MHz sidebands can be elliminated by careful choice of the modulation depths and the relative phase between the modulation signals.
If this condition is realized, the REFL33 signals will have even more immunity to the arm cavity signals because the carrier signal will lose
its counterpart to produce the signal at 33MHz.
Formulation of double phase modulation
m1: modulation depth of the f1 modulation
m2: modulation depth of the f2 (=5xf1) modulation
The electric field of the beam after the EOM
Therefore what we want to realize is the following "extinction" condition
We are in the small modulation regime. i.e. J0(m) = 1, J1(m) = m/2, J2(m) = m2/8, J3(m) = m3/48
Therefore we can simplify the above exitinction condition as
m2 < 0 means the start phase of the m2 modulation needs to be 180deg off from the phase of the m1 modulation.
After some discussion with Koji, I've asked Steve to order some SBP-30+ bandpass filters as a quick and cheap way to help out REFL33. (Also some SBP-60+ for 55MHz, since we only have 1*fmod and 2*fmod bandpasses here in the lab).
For future reference, I've taken spectra of our various RFPDs while the PRMI was sideband locked on REFL33, using a 20dB RF coupler at the RF input of the demodulator boards. The 20dB coupling loss has been added back in on the plots. Data files are attached in a zip.
I also completely removed the cabling for REFLDC -> CM board, since it doesn't look like we plan on using it anytime in the immediate future.
No elog response from outside and no elogd process on nodus, so I restarted it using 'start-elog.csh'.
While meditating over what to do about the fact that we can't seem to hold PRMI lock while reducing the CARM offset, we have started to nucleate a different idea for locking.
We aren't sure if perhaps there is some obvious flaw (other than it may be tricky to implement) that we're not thinking about, so we invite comments. I'll make a cartoon and post it tomorrow, but the idea goes like this.....
Can we use ALS to hold both CARM and DARM by actuating on the ETMs, and sit at (nominally) zero offset for all degrees of freedom? PRMI would need to be stably held with 3f signals throughout this process.
1) Once we're close to zero offset, we should see some PDH signal in REFL11. With appropriate triggering (REFLDC goes low, and REFL11I crosses zero), catch the zero crossing of REFL11I, and feed it back to MC2. We may want to use REFL11 normalized by the sum of the arm transmissions to some power (1, 0.5, or somewhere in between may maximize the linear range even more, according to Kiwamu). The idea (very similar to the philosophy of CESAR) is that we're using ALS to start the stabilization, so that we can catch the REFL11 zero crossing.
2) Now, the problem with doing the above is that actuating on the mode cleaner length will change the laser frequency. But, we know how much we are actuating, so we can feed forward the control signal from the REFL11 carm loop to the ALS carm loop. The goal is to change the laser frequency to lock it to the arms, without affecting the ALS lock. This is the part where we assume we might be sleepy, and missing out on some obvious reason why this won't work.
3) Once we have CARM doubly locked (ALS pushing on ETMs, REFL11 pushing on MC/laser frequency), we can turn off the ALS system. Once we have the linear REFL11 error signal, we know that we have enough digital gain and bandwidth to hold CARM locked, and we should be able to eek out a slightly higher UGF since there won't be as many digital hops for the error signal to transverse.
4) The next step is to turn on the high bandwidth common mode servo. If ALS is still on at this point, it will get drowned out by the high gain CM servo, so it will be effectively off.
5) Somewhere in here we need to transition DARM to AS55Q. Probably that can happen after we've turned on the digital REFL11 path, but it can also probably wait until after the CM board is on.
The potential show-stoppers:
Are we double counting frequency cancellation or something somewhere? Is it actually possible to change the laser frequency without affecting the ALS system?
Can we hold PRMI lock on 3f even at zero CARM offset? Anecdotally from a few trials in the last hour or so, it seems like coming in from negative carm offset is more successful - we get to slightly higher arm powers before the PRMI loses lock. We should check if we think this will work in principle and we're just saturating something somewhere, or if 3f can't hold us to zero carm offset no matter what.
A note on technique: We should be able to get the transfer function between MC2 actuation and ALS frequency by either a direct measurement, or Wiener filtering. We need this in order to get the frequency subtraction to work in the correct units.
As the measurements have been done under feedback control, the lower RF peak height does not necessary mean
the lower optical gain although it may be the case this time.
These non-33MHz signals are embarassingly high!
We also need to check how these non-primary RF signals may cause spourious contributions in the error signals,
including the other PDs.
Since we're having trouble keeping the PRC locked as we reduce the CARM offset, and we saw that the POP22 power is significantly lower in the 25% MICH offset case than without a MICH offset, Rana suggested having a look at the RF spectra of the REFL33 photodiode, to see what's going on.
The Agilent is hooked up to the RF monitor on the REFL33 demod board. The REFL33 PD has a notch at 11MHz and another at 55MHz, and a peak at 33MHz.
We took a set of spectra with MICH at 25% offset, and another set with MICH at 15% offset. Each of these sets has 4 traces, each at a different CARM offset. Out at high CARM offset, the arm power vs. CARM offset is pretty much independent of MICH offset, so the CARM offsets are roughly the same between the 2 MICH offset plots.
What we see is that for MICH offset of 25%, the REFL33 signal is getting smaller with smaller CARM offset!! This means, as Rana mentioned earlier this evening, that there's no way we can hold the PRC locked if we reduce the CARM offset any more.
However, for the MICH offset 15% case, the REFL 33 signal is getting bigger, which indicates that we should be able to hold the PRC. We are still losing PRC lock, but perhaps it's back to mundane things like actuator saturation, etc.
The moral of the story is that the 3f locking seems to not be as good with large MICH offsets. We need a quick Mist simulation to reproduce the plots below, to make sure this all jives with what we expect from simulation.
For the plots, the blue trace has the true frequency, and each successive trace is offset in frequency by a factor of 1MHz from the last, just so that it's easier to see the individual peak heights.
Here is the plot with MICH at 25% offset:
And here is the plot with MICH at 15% offset:
Note that the analyzer was in "spectrum" mode, so the peak heights are the true rms values. These spectra are from the monitor point, which is 1/10th the value that is actually used. So, these peak heights (mVrms level) times 10 is what we're sending into the mixer. These are pretty reasonable levels, and it's likely that we aren't saturating things in the PD head with these levels.
The peaks at 100MHz, 130MHz and 170MHz that do not change height with CARM offset or MICH offset, we assume are some electronics noise, and not a true optical signal.
Also, a note to Q, the new netgpib scripts didn't write data in a format that was back-compatible with the old netgpib stuff, so Rana reverted a bunch of things in that directory back to the most recent version that was working with his plotting scripts. sorry.
Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.
This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 .
This seems untenable . We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.
I've remeasured the QPD ASC sensing coefficients, and figured out what I did weird with the actuation coefficients. I've rearranged the controller filters to be able to turn on the boost in a triggered way, and written Up/Down scripts that I've tested numerous times, and Jenne has used as well; they are exposed on the ASC screen.
All four loops (2 arms * pit,yaw), have their gains set for 8Hz UGF, and have 60 degrees of phase margin. The loop shape is the same as the previous ELOG post. Here is the current on/off performance. The PDH signals (not shown, but in attached xml) show no extra noise, and the low frequency RIN goes down a bit, whic is good. The oplevs error signals are a bit noisier, but I suppose that's unavoidable. The Y-arm performs a bit better than the X-arm.
The up/down scripts don't touch the filters' trigger settings at all, just handles switching the input and output and clearing history. FM1 contains the boost which is intended to have a longer trigger delay than the filters themselves.
Plan C finally worked. We have 1.454mW of AUX X light at the PSL table (2mW incident on the fiber coupler).
Attached is the layout of the telescope.
What I did:
I stuck in Lens 1 (f=200mm) and measured the beam width after the focus of the lens at several points. I fit the data and calculated the beam waist and its position after this lens.
I used the calculated waist and matched it with an appropriate lens and target (fiber coupler) distance. I calculated the maximum coupling efficiency to be 77% for Lens 2 with f=50mm and the fiber coupler placed at 20cm from the waist of Lens1. I was able to obtain 72% coupling after putting the telescope together.
I locked the arms, ran ASS and brought back GTRX to its usual optimum value of ~0.5 counts after closing. We also have the X arm beatnote on the spectrum analyzer.
There are still a couple of things to fix. The rejected beam from the beam sampler has to be dumped using a razor blade.
I found the PSL enclosure open (about a feet wide) on the north side this morning. I am assuming that whoever did the X beatnote alignment last night forgot to close the door to the enclosure before locking attempts
Unfortunately, we only had one good CARM offset reduction to powers of about 25, but then my QPD loop blew it. We spent the vast majority of the night dealing with headaches and annoyances.
Things that were a pain:
I discovered that somehow my Wiener filters that show up in Foton are not the same as what I have in Matlab-land.
I have plotted each of my 3 filters that I'm working with right now (T-240 X, Y and Z for PRCL Pitch) at several stages in the filter creation process. Each plot has:
It's not just a DC gain issue - there's a frequency dependent difference between these filters. Why??
It's not frequency warping from changing between analog and digital filters. The sample rate for the OAF model is 2048Hz, so the effect is small down at low frequencies. Also, the green trace is already discretized, so if it were freq warping, we'd see it in the green as well as red, which clearly we don't.
Has anyone seen this before? I'm emailing my seismic friends who deal in quack more than I do (BLantz and JKissel, in particular) to see if they have any thoughts.
Also, while I'm asking questions, can autoquack clear filters? Right now I'm overwriting old filters with zpk(,,1)'s, which isn't quite the same. (I need this because the Wiener code needs more than one filter module to fit all of the poles I need, and it decides for itself how many FMs it needs by comparing the length of the poles vector with 20. If one iteration needs 4 filter modules, but the next iteration only wants 3, I don't want to leave in a bogus 4th filter.
Here are the plots:
(The giant peak at ~35Hz in the Z-axis fiilter is what tipped me off that something funny was going on)
We wanted to make the PRMI lock more stable tonight, which would hopefully allow us to hold lock much longer. Some success, but nothing out-of-this-world.
We realized late last week that we haven't been using the whitening for the ASDC and POPDC signals, which are combined to make the MICH error signal. ASDC whitening is on, and seems great. POPDC whitening (even if turned on after lock is acquired) seems to make the PRMI lock more fussy. I need to look at this tomorrow, to see if we're saturating anything when the whitening is engaged for POPDC.
One of the annoying things about losing the PRMI lock (when CARM and DARM have kept ALS lock) is that the UGF servos wander off, so you can't just reacquire the lock. I have added triggering to the UGF servo input, so that if the cavity is unlocked (really, untriggered), the UGF servo input gets a zero, and so isn't integrating up to infinity. It might need a brief "wait" in there, since any flashes allow signal through, and those can add up over time if it takes a while for the PRMI to relock. UGF screens reflect this new change.
I wrote the script with the recipe we used, using the Yarm and AS55 on the IN2 of the CM board; however, the steps where the offset should be reduced are not completely deterministic, as we saw that the initial offset (and, therefore, the following ones) could change because of different states we were in. In the script I tried to "servo" the offset using C1:LSC-POY11_I_MON as the reference, but in the comments I wrote the actual values we used during our best test; the main points of the recipe are:
I tried the procedure and it seems fine, as it did during the tries Q and I made; however, since it touches many things in many places, one should be careful about which state the IFO is into, before trying it.
The script is in scripts/CM/CM_Servo_OneArm_CARM_ON.py and in the SVN.
I forgot to elog about these ones, my bad... The new/updated laptops are giada, viviana and paola; paola is already in the lab, while giada and viviana are in the control room waiting for a new home. The Pool of Names Wiki page has already been updated to reflect the changes.
Baja 4.9 m earth quake tripped suspentions, except ETMX Sus damping recovered. MC is locking.
This is good news. It means that the driver probably won't limit the response of the loop - I expect we'll get 20-30 deg of phase lag @ 100 kHz just because of the acoustic response of the AOM PZT + crystal.
I'm leaving the PRC aligned and locked. Feel free to unlock it, or do whatever with the IFO.
I wanted to check the status of the ISS. The AOM driver response was measured on Friday night.
The beam path has not been disturbed yet.
- I found the AOM crystal was removed from the beam path. It was left so.
- The AOM crystal has +24V power supply in stead of specified +28V.
I wanted to check the functionality of the AOM driver.
- I've inserted a 20dB directional coupler between the driver and the crystal.
To do so, I first turned off the power supply by removing the corresponding fuse block at the side panel of the 1X1 Rack.
Then ZFDC-20-5-S+ was inserted, the coupled output was connected to a 100MHz oscilloscope with 50Ohm termination.
Then plugged in the fuse block again to energize the driver box.
Note that the oscilloscope bandwidth caused reduction the amplitude by a factor of 0.78. In the result, this has already been compensated.
- First, I checked the applied offset from a signal generator (SG) and the actual voltage at the AOM input. The SG OUT
and the AOM control input are supposed to have an impedance of 50Ohm. However, apparently the voltage seen at the
AOM in was low. It behaved as if the input impedance of the AOM driver is 25Ohm.
In any case, we want to use low output impedance source to drive the AOM driver, but we should keep this in mind.
- The first attachment shows the output RF amplitude as a function of the DC offset. The horizontal axis is the DC voltage AT THE AOM INPUT (not at the SG out).
Above 0.5V offset some non linearity is seen. I wasn't sure if this is related to the lower supply voltage or not. I'd use the nominal DC of 0.5V@AOM.
The output with the input of 1V does not reach the specified output of 2W (33dBm). I didn't touch the RF output adjustment yet. And again the suppy is not +28V but +24V.
- I decided to measure the frequency response at the offset of 0.53V@AOM, this corresponds to the DC offset of 0.8V. 0.3Vpp oscillation was given.
i.e. The SG out seen by a high-Z scope is V_SG(t) = 1.59 + 0.3 Sin(2 pi f t) [V]. The AOM drive voltage V_AOM(t) = 0.53 + 0.099 Sin(2 pi f t).
From the max and min amplitudes observed in the osciiloscope, the response was checked. (Attachment 2)
The plot shows how much is the modulation depth (0~1) when the amplitude of 1Vpk is applied at the AOM input.
The value is ~2 [1/V] at DC. This makes sense as the control amplitude is 0.5, the applied voltage swings from 0V-1V and yields 100% modulation.
At 10MHz the first sign of reduction is seen, then the response starts dropping above 10MHz. The specification says the rise time of the driver is 12nsec.
If the system has a single pole, there is a relationship between the rise time (t_rise) and the cut-off freq (fc) as fc*t_rise = 0.35 (cf Wikipedia "Rise Time").
If we beieve this, the specification of fc is 30MHz. That sounds too high compared to the measurement (fc ~15MHz).
In any case the response is pretty flat up to 3MHz.
I pulled out the Fiber Optic Module for FOL from the rack inside the PSL table enclosure and modified it. The beat PDs were moved into the box to avoid breaking the fiber pigtail input to the PD.
The box has 3 input FC/APC connectors (PSL and AUX lasers) and 2 output FC/APC connectors (10% of the beatnote for the AUX lasers).
Attachment shows what is inside the box. The box will again go back on the rack inside the PSL enclosure.
Just now we had another EPICS freeze. The network was still up; i.e. I could ssh to chiara and fb, who both seemed to be working fine.
I could ping c1lsc successfully, but ssh just hung. fb's dmesg had some daqd segfault messages, so I telnet'ed to daqd and shut it down. Soon after, EPICS came back, but this is not neccesarily because of the daqd restart...
Yesterday morning was dusty. I wonder why?
The PRM sus damping was restored this morning.
Yesterday afternoon at 4 the dust count peaked 70,000 counts
Manasa's alergy was bad at the X-end yesterday. What is going on?
There was no wind and CES neighbors did not do anything.
We kept struggling with the PRMI, although it was a little better than yesterday:
So, still no exciting news, but PRMI lock seems to be improving a little.
We were at the X end today trying to couple AUX X light into the fiber.
The proposed plan still did not give a good beampath. The last steering mirror before the fiber coupler was sticking out of the table enclosure. I tried a few other options and the maximum coupling that I could get was ~10%
I am working on plan C now; which would be to use fixed mount mirrors and steer the beam to the space created by Koji near the IR trans path and use a set of lenses instead of a single lens. I will elog more details after some modematching calculations.
We moved one of the clamps for the doubling crystal to make space. Also, the NPRO current was reduced during this work.
I reset things to how they were before I touched the table. I ensured that the green power was still the same (~3mW) after the doubler and that it could lock to the arm in TEM00.
Tonight was a sad night... We continued to pursue our strategy, but with very poor results:
The X end fiber setup will be put together tomorrow morning. Let me know if there are any concerns.
It is certain that we have space issues at the X end that has been preventing us from sticking in a lens to couple light into the fiber.
The only way out is to install a platform on the table where we can mount the lens. I have attached the a photo of how things look like at the X end (attachment 1) and also a drawing of the platform that which can hold the lens (attachment 2). Additional support to the raised platform will be added depending on how much space we can clear up on the table by moving the clamping forks of the doubler.
Steve and I have been able to gather parts that can be put together into something similar to what is shown in the drawing.
Proposed modifications to the X end table:
1. The side panels of the table enclosure will come out while putting in the new platform.
2. The clamping forks for the doubling crystal will be moved.
Let me know of any concerns about the proposed solution.
The components of the RF amplifier box are in place. The RF amplifier box has been mounted on the IOO rack and the front panel connections have been labeled. Attached is the photo of how things look in the inside for future reference.
Sometime in the next few days the box will be pulled out to replace the panel mount SMA barrels in the front with insulated ones.
I opened up the spaghetti pot over the vertex seismometer, and taped the cable to the slab. The way the cable is coiled, it was touching the underside of the seismometer. Now the only connection is at the cable connector. There is a ~few inch bit of cable, then it's taped down.
We had persistent frustration by occasional unlock during ASSing.
Today, I added triggers to the servo gains in order to elliminate this annoyance.
Each ASS servo gain slider is multiplied with the corresponding LSC Trigger EPICS channel (i.e. C1:LSC-iARM_TRIG_MON, where i=X or Y).
This has been done by ezcaread modules in RCG.
The model and screen have been commited to svn.
Please remember that Xarm ASS needs FM6 (Bounce filters) to be ON in order to work properly.
c1lsc had 60 full-rate (16kS/s) channels to record. This yielded the LSC to FB connection to handle 4MB/s (mega-byte) data rate.
This was almost at the data rate limit of the CDS and we had frequent halt of the diagnostic systems (i.e. DTT and/or dataviewer)
Jenne and I reviewed DAQ channel list and decided to remove some channels. We also reviewed the recording rate of them
and reduced the rate of some channels. c1lsc model was rebuilt, re-installed, and restarted. FB was also restarted. These are running as they were.
The data rate is now reduyced to ~3MB nominal.
The following is the list of the channels removed from the DQ channels:
The following is the list of the channels with the new recording rate:
At the lunch meeting, we were thinking about the exess high frequency content of the MICH control signal, which leads to railing against the FM output limiter and lock loss. I propsed that POPDC sensor/ADC noise was the culprit.
In short, I was wrong. Just now, I locked the PRMI with a MICH offset as we normally do, and then froze the POPDC output. The MICH spectrum did not change in any noticible way.
However, increasing the analog ASDC whitening gain showed a direct improvement of the error signal noise floor, and thus a reduction in the control signal spectrum. I.e. we have been suffereing from ASDC ADC noise.
We had previously set the ASDC whitening gain so that half fringe of the PRMI would be well within the ADC range, but since we're actually only ever going to 25%, I feel fine upping this gain. Interestingly, when increasing the whitening gain by 12dB, the control signal spectrum has fallen by more like 20 dB in the 400Hz-1kHz region, which is great.
The only potential hurdle I can think of is that when we start reducing the MICH offset at zero CARM offset, we may approach ADC saturation in ASDC before we can hand off to RF signals, in which case we would have to dynamically lower the whitening gain, which introduces offsets, which could get hairy. But, since MICH railing has been directly seen to lead to lock-loss, I'd rather solve that problem first.
[Diego, Jenne, Eric]
Tonight we kept on following our current strategy for locking the PRFPMI:
both of the last two locks, the most stable ones (one transition to usual REFL11 and one transition to "CM_SLOW" REFL11) were acquired actuating on MC2;
EDITs by JCD: At least one of the times that we lost PRMI lock (although kept CARM and DARM lock on ALS), was due to MICH hitting the rail, even after we increased the limiter to 15,000 counts.
Here is the transfer function between CARM ALS (CARM_IN1) and REFL11 coming through the CM board (CARM_B), just before we transitioned over. Coherence was taken simultaneously as usual, I just printed it to another sheet.
Here is the lockloss plot for the very last lockloss. This is the time that we were sitting on REFL11 coming through the CM_SLOW path. A DTT transfer function measurement was in progress (you can see the sine wave in the CARM input and output data), but I think we actually lost lock due to whatever this glitch was near the right side of the plots. This isn't something that I've seen in our lockloss plots before. I'm not sure if it's coming from REFL11, or the CM board, or something else. We know that the CM board gives glitches when we are changing gain settings, but that was not happening at this time.
Q: Here's the SR785 TF of CARM locked through CM board, but still only digital control; nothing exciting. Excitation amplitude was only 1mV, which explains the noisy profile.
I pulled out the RF amplifier box from the IOO rack again and added the new RF amplifiers for FOL.
I replaced one of the decoupling capacitors of the ALS beat note RF amplifier ; the poloproylene capacitor with a ceramic capacitor (0.1uF) .
After putting back the box, I confirmed that we had a beat note. I did not get a chance to measure the ALS noise after putting back the box because the IFO was already occupied.
I will post a detailed elog of the components in the RF amplifier box once I am done with it (hopefully tomorrow)!
I have removed REFLDC and the SR560 offsetter from the CM board IN2. Now, analog AS55 I lives there, for our single arm testing. (Analog I has more of the single arm Y PDH signal in it). REFL11 has been reconnected to IN1.
With ITMX super misaligned, Diego and I locked the Y-arm with the AO path on AS55, ultimately at 4kHz bandwidth, but with plenty of gain margin. We didn't allocate the gains too intelligently, and had the CM board input gain slider maxed out, but plenty of headroom in the digital and AO sliders, making it inconvenient to up the UGF even more, to engage the super boosts. However, since this is just a test case to make sure we still can AO lock, I'm not too worried about this.
Since LSC FMs and such had changed around, old recipies didn't neccesarily work 1:1. Diego is writing a script for the current recipe, and will post an elog with the steps.
Gains and signs are able to be tracked by loop TFs, the real sticking point is a stable crossover. We used the 1.6k:80 hardware filter in the CM board to give the AO Path a 1/f shape in the crossover region, and undid it digitally in the CM_SLOW input FM. However, we do use a 300:80 in the MC2 sus FM to make the digital loop like 1/f^2 around the crossover, once a little bit of AO has come in to pull up the digital loop's phase. We used the CARM filter bank to do this, so I think we should be able to use a similar technique to do it in the PRFPMI case, as long as the coupled cavity pole is around ~100Hz.
Attached are a few OLTFs from the progression.
The N2 pressure reading (C1:VAC-N2PRES) is now up-to-date after rebooting c1vac1.
The vaccum system is "Vacuum normal". We now have a space pressure transducer.
Our vacuum valves are manipulated with 60~75 PSI of nitrogen. All the valves are configured to be closed in the case of low N2 supply pressure.
In order to avoid this safety shutdown accidentally triggered, we have two N2 cylinders to sustain the vacuum valves. When one cylinder goes to low
the mechanical valve switches over to the other cylinder.
We have the monitor channel for this (combined) cylinder pressure. One shoulbe be able to see periodical pressure variation when the auto cylinder
switch is operating. However, the nirogen pressure reading got stuck at 66 PSI on Dec.16, 2014 (See attached 60-day plot of N2 supply pressure).
What we did
This morning we tracked down the cause of the trouble. We first closed the valves on EPICS and started to vary the N2 pressure.
Our first guess was the pressure transducer (Omega #236PC100GW) that was already 15 yrs old. We even has a sensor spare for replacement.
But it turned out that the direct voltage reading (to be 1mV/PSI) is changing correctly. The second guess was Omega Controller-Monitor
#DPiS32-C24 that is reading the voltage from the tranceducer. The display on this small black unit was changing corresponding to the
So our thought was
1) RS232C of the monitor unit is not working correctly
2) c1vac1 is not communicating with the monitor unit.
We wondered what could cause c1vac1 not communicating with the monitor unit, but we were afraid that some function got stuck
during either the nodus upgrade or chiara rebooting (or something else). So we decided to reboot c1vac1
In order to avoid any glitch in the main vacuum pressure, Steve disconnected some of the controller connectors for the closed valves.
We did this treatment before and it was successful.
Then c1vac1 was rebooted just by telnet and type reboot in the terminal.
Once the target is back in action, we noticed that the monitor value started to move.
Steve reverted the cables to the valves and operated the valves to recover "Vacuum Normal" state. Everything is now nicely settled.
Today (after centering the POP QPD), I measured the PRM to POP QPD transfer functions. I am suspicious that this was part of my problem last week. Since most of the angular noise is coming from the folding mirrors, but I can't actuate on them, I need to know (rather, the Wiener calculator needs to know) how actuating on the PRM will affect the spot at the POP QPD.
For the plots below, I have cut out any data points that have coherence less than 0.95. I may want to go back and fill in a little bit some of the areas (particularly around 3Hz) that I had trouble getting coherence in.
Using these to prefilter my witness data, I am failing to calculate a Wiener filter. I have tried the Levinson algorithm, as well as brute-forcing it, but I'm too close to singular for either to work. I am able to calculate a set of Wiener filters without the prefiltering, or with a dummy very simple prefilter, so it's not inherently in the calculators. Separately, I can plot my vectfit-ed actuator TFs, and I can convert them to a discrete fiilter with the bilinear transform, and then use sosfilt to filter some white noise data, which comes out with the shape I expect. So. It's not inherently the filters either. More work to do, when it's not 4am.
Here are the measured actuator transfer functions. They were measured as usual with DTT, but since the measurement kept getting interrupted (MC unlock, or I wanted to add more integrations or more cycles), these are several different DTT files stitched together. In both cases I am acuating PRM's ASC[pit, yaw] EXC point, and looking at the POP QPD.