DC power supplies for the RF generation box are now in place. They are the top two of the 6 Sorensens in the OMC short rack next to 1X2.
We made the connections as we did for the RF distribution box, the power supplies labele, and the cables strain-relieved.
The power supply is not yet connected to the actual RF generation box. This should be done by Suresh or someone with the supervision of him.
We have two +18V supply on the short OMC rack, in total. One is for the RF source, the other is for the OMC PZTs, whitening, etc.
This is to avoid unnecessary ground loop although the grounding situation of the OMC side is not known to me.
I have checked the voltages on the connector. They are okay and I have plugged in the Sorensen power into the RF Source. The ground reference for the Sorensens comes from the 1X2 Rack ground reference lines on the south side of the rack.
I looked for the OMC ground reference. Could not find one on either of the the OMC half racks.
We have two +18V supply on the short OMC rack, in total. One is for the RF source, the other is for the OMC PZTs, whitening, etc.
This is to avoid unnecessary ground loop although the grounding situation of the OMC side is not known to me.
East arm cabinet E9 and E10
[Steve, Koji, Suresh]
We shifted two Sorensen power supplies from the Auxiliary rack next to 1X2 to 1Y2. And have installed them there (pic below). The local ground reference was picked up from the racks ground reference. A shielded cable with two twisted pairs was used to make a new power cable for the RF rack. Since we are using three of the four conductors (+18,+28 and ground), one of them is not connected to anything. This situation can be improved in a future iteration when, for example, we might wish to relocate the Sorensens to a different rack.
We are still working on changing the power supply to the RF source. Will complete this early next week
General ISS Design
Signals through the ISS are directed as follows: an error signal is obtained by summing the ~5 V signal from the PD with a -5 V signal from a high precision voltage regulator (which is first filtered with an ~ 30 mHz low-pass Sallen-Key filter). It is this signal that is processed/amplified by the servo. The output from the servo is then used to drive an AOM (it is not known exactly how this is done and whether or not any preamplifier/extra circuitry is necessary). The resulting modulation, hopefully, reduces fluctuations in the laser intensity incident on the PD, lowering the relative intensity noise.
Almost the entirety of my focus has been directed toward designing the servo portion of the ISS. Speaking in general terms, the currently proposed design consists of stages of active op-amp filters, but now the stages will have internal switches that allow them to switch between ‘flat’ gain buffers and more complicated filters with our desired behavior. Consider some Example Filter Stages where I have demonstrated a typical switching filter with the switch open and closed. When the switch is closed, the capacitor is shorted and we simply have a variable gain buffer (variable in the sense that its gain can be tuned by proper choice of the resistances) with no frequency dependence. When the switch is open, the capacitor introduces a pole at ~100 Hz and a zero at ~1 kHz.
CircuitLab has decent analysis capabilities and attached are plots generated by CircuitLab. The first plot corresponds to a frequency analysis of the voltage gain of op-amp U1 and the ‘flat’ ~20 dBV gain filter with the switch closed and the capacitor shorted. The second plot is the same frequency analysis, but now with op-amp U2 and the filter with the switch open and the capacitor introduced into signal processing. This particular combination of resistors and capacitors produce a DC gain of 60 dBV, a pole at ~100 Hz, a zero at ~10 kHz and high frequency behavior of ~constant gain of 20 dBV. In this simulation, the gain-bandwidth product of the simulated op-amp (the standard op-amp CircuitLab uses) was artificially increased in order to see more ideal behavior in the higher frequency domain.
Switches like the above can be used to add boosts to some initial filter state (which could be like the above or possibly a simple integrator to achieve high DC gain) and change it into a more complex and more useful filter state advantageous for desired noise suppression. Cascades of these switching filters could be used to create very complicated transfer function behavior. No general servo has yet been designed as the exact details of the intensity noise requirements are still being determined.
With regards to the implementation of the switches, some ‘smart’ signal will be used to trigger a switch opening and the boost being introduced to the signal processing. The switches will be opened (open corresponds to adding the boost) in a manner that maintains stability of the servo circuit. Essentially, some sort of time delay or power monitor induced signal (power from the PD output) will be used to modify the servo's behavior.
How exactly the signal will drive the AOM for correct noise suppression is unknown currently.
tonight we worked on the tuning of the double demod phases for the handoff of the short DOFs control signals.
Only MICH can now undergo the handoff. PRC can't make it.
Basically, we tuned the PD6 demod phase and reduced the offset in PD6_I. Then we tuned the relative gain of PD6_I and PD2_I so that the two open loop transfer function of the control loops would match. We tried that in several ways and several times but without success.
I guess we're missing to do/check something.
This afternoon I tuned the handoff script for the SRC, after that Rob eralier during the day had already adjusted that for PRC. To do that, I followed the procedure in the Wiki.
After that the SRC could get locked with the double demod signals. the open loop transfer function emasurement on the PRC loop showed that it was nearly unstable. Rob reduced a little its gain to improve the stability.
The DD handoff is now working and we can get back to locking the interferometer.
Rana, Alberto, Pete
We have the DD handoff nominally working. Sometimes, increasing the SRC gain at the end makes MICH get unstable. This could be due to a non-diagonal term in the matrix, or possibly because the DRM locks in a funky mode sometimes.
To get the DD handoff working, first we tuned demod phases in order to zero the offsets in the PD signals handed-off-to. Based on transer function measurements, I set the PRC PD6_I element to 0.1, and set the PD8_I signal to 0, since it didn't seem to be contributing much. We also commented out the MICH gain increase at the end of the DD_handoff script.
It could still be more stable, but it seems to work most of the time.
I had trouble getting the SRC handoff from SD to DD to work. I tried different gains, flipping the PD7 & 8 demod phases by 180 degrees, and messing with the output matrix to reduce cross-couplings in the state with MICH & PRC on DD and SRC on SD. Eventually I decided to try to make the DRM matrix diagonalization work.
It does, mostly. The handoff is now stable, and the loops all have UGFs around 100Hz. So, tonight anyways, it's possible to run senseDRM and then loadDRMImatrixData.m and run the resulting tdswrite command, and have a working handoff. I had to eliminate a few PDs (PD5 & PD10) to get it to work properly.
It would be nice if this script would measure all the PDs and allow individual setting of loop UGFs and measurement frequencies.
We worked on tuning the DD handoff tonight. We checked the DD PD alignments and they looked fine. First I tuned the 3 demod phases to minimize offsets. Then I noticed that the post-handoff MICH xfer function needed an increase in gain to look like the pre-handoff xfer function (which has a UGF of about 25 Hz). I increased the MICH PD9_Q gain from 2 to 7 in the input matrix. But, the handoff to PRC still failed, so tomorrow we will try to find out why.
In the plot, ref0 is before MICH handoff, and ref1 is after MICH handoff. There is also a PRC trace (before PRC handooff).
I added an MEDM screen for the DFD to the GREEN screen. It is displayed in the attached screen shot.
This screen is located in: /cvs/cds/rtcds/caltech/c1/medm/c1gfd/C1GFD_DFD.adl
This is a plot showing the old filters and the new ones we added this morning.
The new ones have a Cheby for AC coupling below 10 Hz and then a 500 Hz LP after the mixer. The LP frequency has been increased so that we can use this signal in a feedback loop to the ETM with a ~100 Hz UGF.
I've had a go at trying to estimate the frequency noise of the digital frequency discriminator (DFD). I input a 234.5Hz (0.5Vpp) signal from a 30MHz function generator into the ADC. The LP output of the DFD measured 234.5Hz. However, this signal is clearly modulated by roughly +/- 0.2Hz at harmonics of 234.5Hz (as you can see in the top plot in the dataviewer screenshot below). So the frequency noise can be estimated as rms of approximately 0.2Hz.
This is supported by taking the spectra of the LP output and looking at the RMS. Most of the power in the RMS frequency noise (above the minimum frequency) comes from the harmonics of the input signal and the RMS is approximately 0.2Hz.
I believe this stems from the rather basic LP filter (three or four poles around 10Hz?) that is used in the LP filter to remove the higher frequency components that exist after the mixing stage. (The currently loaded LPF filter is not the same as the saved one in Foton - and that one won't load at the moment, so I'm forced to remember the shape of the current filter).
The attached screen capture from data viewer shows the LP_OUT hovering around 234.5Hz.
Here is the spectrum of the input into the DFD (a 234.5Hz sine wave, 0.5 Vpp) and the spectrum and RMS of the LP output. The linewidth of the input signal is clearly much less than 0.1Hz, where as the RMS noise (above 2mHz) is approximately 0.2Hz and the main contributions are clearly the harmonics of the 234.5Hz signal.
Joe injected a 234.567 etc. Hz sine wave into the excitation channel in the DFD INPUT filter. The spectrum of the output of the LP filter with the new filter is shown below with the RMS calculated from 300Hz down to 1mHz - see first attachment. The RMS is equal to about 2.5Hz. (Incidentally, the RMS is very much higher (slightly less than 400Hz - see second attachment) if you calculate it from 7kHz down to 1mHz).
I've been thinking a bit about what the ideal cable length / delay time for the upgraded ALS beatbox should be. Here are some thoughts, but no conclusions yet.
If you're not running your beatbox mixer in compression, there are two competing effects when you change the cable length. At first, more delay gives better sensitivity, but this does not go on to infinity, because cable attenuation eventually kills your signal. It turns out that the ideal length can be derived to be whatever length gives you 20/ln(10) = -8.7dB of attenuation. Frank found this out in PSL ELOG 825, and I found an HP document that derives this (and other useful DFD math) to the wiki, here.
In PSL ELOG 826, Frank calculated this ideal length for a 160MHz carrier in various kinds of cables.
However, this is not the end of the story. In the case of the DFD, we actually benefit from operating the mixer in compression, as makes our sensitivity less sensitive to flucuations in the beat amplitude. In this situation, the HP doc states "For maximum sensitivity, more delay can be added until the signal level out of the delay line is 8.7dB below the phase detector (mixer) compression point." I'm not sure I really understand the logic behind this statement, though.
Lastly, Koji mentioned the fact that the splitter in the demod board does not split at exactly 90 degrees, making the trajectory in the IQ plane an ellipse. This means that if the beat signal is moving around the ellipse a lot, or even wrapping around it, we can suffer from some nonlinear signal conversion. Also, if the raw DFD sensitivity is very high, the free swinging mirrors will cause the signal to swing around faster than the phase tracker can keep up. This should be easy to avoid, however; I doubt we will use so much cable that the beat would move by so much.
I intend to take all of this into account when picking a cable length! Jessica is going to help us make a nice box for them, too.
This afternoon, I had a fruitful conversation with Rich Abbott about various kinds of cables.
I've sent an email to Steve to ask him to buy 2 x 50m LMR-195 cables, with male SMA connectors. Rich highly recommends these for their polyethylene insulation, which makes them less microphonic and less susceptible to thermal expansion, low loss, and multi-ply bonded foil shielding.
50m means that the peak to peak mixer output swing corresponds to about a MHz. 1nV of mixer output noise looks like ~6mHz frequency noise, for a Level 3 mixer appropriately driven. As a comparison, the lowest our in-loop green PDH error signals get is 0.1Hz/rtHz.
The cable attenuation should be around 4.2dB at 50MHz, and 7.3dB at 150MHz, according to the data sheet. Thus, we should not be in the regieme where we are losing sensitivity to the attenuation.
By my rough geometric estimation, these two should fit in the 2U box I got ahold of today fine. Jessica is designing the front panel.
We currently have ~30m of RG-408 and RG-142 as our delay lines.
There are no unexpected red-flags in the performance of the DFD electronics. The calibration factors for the digital phase tracker system are 71.291 +/- 0.024 deg/MHz for the X delay line and 70.973 +/- 0.024 deg/MHz for the Y delay line, while the noise floor for the frequency noise discrimination is ~0.5 Hz/rtHz above 1 Hz (dominated by ADC noise).
Conclusion and next steps:
I still don't know what's responsible for the anomalously low noise levels reported by the ALS-X system sometimes. Next test is to check the EX PDH system, since on the evidence of these tests, the problem seems to be imprinted on the light (though I can't imagine how the noise becomes lower?).
Details and discussion: (diagrams to follow)
A couple of months ago, I took 21 measurements of the delay line transfer function. As shown in Attachment #2, the unwrapped phase is more consistent with a cable length closer to 45m rather than 50m (assuming speed of light is 0.75c in the cable, as the datasheet says it is).
Attachment #1 shows the TF magnitude for the same measurements. There are some ripples consistent with reflections, so something in this system is not impedance matched. I believe I used the same power splitter to split the RF source between delayed and undelayed paths to make these TFs as is used in the current DFD setup to split the RF beatnote.
I had made some TF measurements of the delay sometime ago, need to dig up the data and see what number that measurement yields.
The forthcoming Acromag c1susaux is supposed to use the backplane connectors of the sus euro card modules.
However, the backplane connectors of the vertex sus coil drivers were already used by the fast switches (dewhitening) of c1sus.
Our plan is to connect the Acromag cables to the upper connectors, while the switch channels are wired to the lower connector by soldering jumper wires between the upper and lower connectors on board.
To make the lower 96pin DIN connector available for this, we needed DIN 41612 (96pin) shroud. Tyco Electronics 535074-2 is the correct component for this purpose. The shrouds have been installed to the backplane pins of the coil driver circuit D010001. The shroud has the 180deg rotation dof. The direction of the shroud was matched with the ones on the upper connectors.
The PCB board of the adapter for DIN 96pin to DSUB37 conversion (single DSUB version) was delivered yesterday and I quickly soldered the connectors.
They are ready for use and stored in a JLCPCB cardboard box on a pile of acromag stuff. (Note that the lacel is written on the box with Sharpie)
I installed 6 of these in 1Y2. Three were for PD INTF #1-3, and I used three more for the AS110, REFL11, and REFL33 Demod board FEs, where the strain-reflief of the DC power cables to the Eurocrate was becoming a problem. So now there are only 4 units available as spares.
Once the strain-relieving of the Dsub cabling to 1Y3 is done, we can move ahead with testing. I'd like to put this to bed this week if possible.
I set up an action cam (DJI OSMO Pocket) and brought it back to the 40m. The kit is now placed in the control room cabinet together with the Canon DSLR.
I might have left the USBC chaging cable at home this time. Will bring it back next time.-> The cable was returned to the kit on Oct 23rd.
We found that DMF/ was not an SVN working copy, so I wiped out the SVN version, imported the on-disk copy, moved it to DMFold/ and then checked out the SVN version.
We can delete DMFold/ whenever we are happy with the SVN copy.
I (think I) restarted DMF. It's on Mafalda, running in matlab (not the complied version which Rana was having trouble with back in the day). To start Matlab, I did "nohup matlab", ran mdv_config, then started seisBLRMS.m running. Since I used nohup, I then closed the terminal window, and am crossing my fingers in hopes that it continues to work. I would have used Screen, but that doesn't seem to work on Mafalda.
Just kidding. That plan didn't work. The new plan: I started a terminal window on Op540, which is ssh-ed into Mafalda, and started up matlab to run seisBLRMS. That window is still open.
Because Unix was being finicky, I had to open an xterm window (xterm -bg green -fg black), and then ssh to mafalda and run matlab there. The symptoms which led to this were that even though in a regular terminal window on Op540, ssh-ed to mafalda, I could access tconvert, I could not make gps.m work in matlab. When Rana ssh-ed from Allegra to Op540 to Mafalda and ran matlab, he could get gps.m to work. So it seems like it was a Unix terminal crazy thing. Anyhow, starting an xterm window on Op540m and ssh-ing to mafalda from there seemed to work.
Hopefully this having a terminal window open and running DMF will be a temporary solution, and we can get the compiled version to work again soon.
While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.
Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.
We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.
Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.
I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.
I've brought 4 DO-32L-PE cards from WB for BHD upgrade for Jon.
I have added a DQ block to the sus_single_control library part. This means that all sus models will automatically generate DQ channels based on what is specified in this doc block:
So for instance, for BS will have the following DQ channels:
etc. The channels names modified by the activateDQ.py script after install are still modified appropriately.
This is now the place where we should be maintaining DQ channels.
I have copied over the complete frame files from two DRFPMI lock acquisitions + locks to /frames/archive. The data should be safe from the wiper script here.
One, under the subfolder DRFPMI_Mar29_cal is the lock where the CAL-DARM channel is properly calibrated at GPS time 1143274087.
The other lock, under DRFPMI_MAR29_nocal, does not have the calibration set up yet, but was a much quicker acquistion (<2 min from ALS acquisition to DRFPMI) and longer lock (~8min).
Three RF-only locks longer than a minute tonight, out of 5 total attempts.
Last week, I determined that the beam spot on the RF POP PD is too large. This still needs to be fixed. I updated the ASS model to use REFLDC as a PRCL dither error signal; it works.
There seems to be some excess angular motion of ETMY tonight. This is evident in the oplev spectra (as compared to ETMX), and the GTRY camera, and even the retroreflected beam from a misalgined ETMY on the ITMY face when the PRC is carrier locked.
Gautam and I mostly focused on setting up the CAL-DARM_CINV block to produce this (mostly) calibrated spectrum starting from GPS 1143274087. [Darm on unwhitened AS55, DRMI on 3F, one CARM boost]
Here are the control and error signal spectra:
[DTT files attached]
Note to self: archive some of this data
For real this time.
Fast ALS was still a problem tonight. I don't think high frequency ALS noise saturating the PC drive is the issue; I put two 10k poles before the CM board (shooting for just 2-3kHz bandwidth), and the PC drive levels would be stable and low up until the lockloss, which was always conincident with a step in the AO gain.
After working with that for a few hours, we turned back to our more standard locking attempts. First, we dither aligned the PRMI, and then centered the REFL beam on REFL11. It's hard to say for certain, but we may have been a little close to the edge of the PD. The only other thing that differed from Monday's attempts was using 6dB less AO gain when trying the up the overall gain.
The script now reliably breaks through to stable high powers, we had a handful of pure-RF locks tonight. The digital DARM gain needs tuning, and the CARM bandwidth still isn't at its final state, but these are very tractable. Off the top of my head, the way forward now includes:
Unrelated: I feel that the PRC angular FF may have deteriorated a bit. I'm leaving the PRC locked on carrier to collect data for wiener filter recalculation.
in addition to Koji's words I feel like we should also thank those who made small but positive contributions. Its hard not to notice that this locking only happened after the new StripTool PEM colors were implemented...
From the times series plot I guess that the fuzz of the in-loop DARM is 1 pm RMS (based on memory). This means that the ALS was holding the DARM at 10 pm from the RF resonances.
There is no significant shift in the DRMI error signals, so new weird CARM effect. Would be interesting to see what the 1f signals do in the last 60 seconds before RF lock.
For documentation, perhaps Gautam can post the loop gain measurements of the 5 loops on top of the Bode plots of the loop models.
We worked on getting the DRFPMI back up and running, hoping the ALS performance was good enough.
We did succeed in bringing in enough of the AO path to stabilize arm powers > 100, but failed at the full RF DARM handoff.
REFL165 angle was adjusted to -86 to minimize PRCL in the Q signal.
The AS110 signals are mysteriously huger than they used to be. Whitening gain reduced to 15dB from 27dB. Old trigger thresholds are still fine.
The new AUX X laser has a different sign for the temperature-> frequency coupling, so our usual convention of "beatnote goes up when temp slider goes up" meant the ALSX input matrix elements had to change sign.
We think the POPDC PD (which I think is the POP2F PD) may be miscentered, since in PRMI configuration, its maximum does not coincide with the REFLDC minimum, and leaves a sizeable TEM10 lobe on the REFL camera. This was a pain.
Highlight of the night: the DRFPMI was held at arm powers > 110 for 20 seconds. ALS feedback was still running though, but so was some nonzero REFL11 AO path action.
In short, time was spent finding the right FM trigger settings to keep the DRMI locked while CARM is fluctuating through resonance, what CARM offset to acquire DRMI lock at, order of operations of turning on AO / turning up overall CARM gain, etc.
Sadly, for the past hour or so, the DRMI has refused to stay locked for more than ~20 seconds, so I haven't been able to push things much further. This is a shame, since I'm very nearly at the equivalent point in the PRFPMI locking script where the ALS control is turned off completely.
Progress was made. CARM was stably locked on RF only. DARM was RF only for a few moments before I typed in a wrong number...
A change was made to the LSC model's triggering section to make the DRMI hold more reliably at zero CARM offset. Namely, the POPDC signal now has its absolute value taken before the trigger matrix. Even unwhitened, it occaisionally would somehow go negative enough to break the DRMI trigger.
AUX X laser was acting up again. As before, tweaking laser current is the temporary fix.
Please clarify: I wonder if you were at the zero offset for CARM and DARM or not. I am 25% excited right now.
Please clarify: I wonder if you were at the zero offset for CARM and DARM or not.
Yes, this was at the full DRFPMI resonance.