For my note-taking:
If I missed any of the tests we discussed, please add them here.
I thought I'd get started on some of the tests tonight. But I found that this problem had resurfaced. I don't know what's so special about the REFL55 photodiode - as far as I can tell, other photodiodes at the REFL port are running with comparable light incident on it, similar flat whitening gain, etc etc. The whitening electronics are known to be horrible because they use the quad LT1125 - but why is only this channel problematic? To describe the problem in detail:
I request Koji to look into this, time permitting, tomorrow. In slightly longer term, we cannot run the IFO like this - the frequency of occurrence is much too high and the "fix" seems random to me, why should sweeping the whitening gain fix the problem? There was some suggestion of cutting the PCB trace and putting a resistor to limit the current draw on the preceeding stage, but this PCB is ancient and I believe some traces are buried in internal layers. At the same time, I am guessing it's too much work to completely replace the whitening electronics with the aLIGO style units. Anyone have any bright ideas?
Anyway, I managed to lock the PRMI (ETMs misaligned) using REFL165I/Q. Then, instead of using the BS as the MICH actuator, I used the two ITMs (equal magnitude, opposite sign in the LSC output matrix).
I didn't get around to running any of the other tests tonight, will continue tomorrow.
Update Mar 26: Attachments #2 and #3 show that there is clearly something wrong with the whitening electronics associated with REFL55 channels - with the PSL shutter closed (so the only "signal" being digitized should be the electronics noise at the input of the whitening stage), the I and Q channels don't show similar profiles, and moreover, are not consistent (the two screenshots are from two separate sweeps). I don't know what to make of the parts of the sweep that don't show the expected "steps". Until ndscope gets a log-scaled y-axis option, we have to live with the poor visualization of the gain steps which are dB (rather than linearly) spaced. For this particular case, StripTool isn't an option either because the Q channel as a negative offset, and I opted agains futzing with the cabling at 1Y2 to give a small fixed positive voltage instead. I will emphasize that on Friday, this problem was not present, because the gain balance of the I and Q channels was good to within 1dB.
It might be a good idea to configure this box for the new suspension config - modern Satellite Amp, HV coil driver etc. It's a good opportunity to test the wiring scheme, "cross-connect" type adapters etc.
Next, the feedthroughs need to be wired and the channels need to be bench tested.
The servos are almost certainly not optimal - but we have the IFO sort of working, so before we make any changes, let's make a strong case for it. Once the loop TFs and noises (e.g. the sensing noise reinjection you maybe saw) are fully characterized and a new loop is shown to perform better, then we can make the changes, but until then, let's continue using the "nominal" configuration and keep all the WFS loops on . I turned everything back on.
BTW, MC2_ASCPIT_IN1 isn't the correct channel to measure the sensing noise re-injection, you need some other sensor, e.g. is the MC transmission (de)stabilized. 0-20 Hz is where I expect the WFS is actually measuring above the sensing noise.
Since I am mainly concerned with the actuator part of the OSEM, I chose to do this measurement at the output cables for the coil drivers in 1X4. See schematic for pin-mapping. There are several parts in between my measurement point and the actual coils but I figured it's a good check to figure out if measurements made from this point yield sensible results. The slow bias voltages were ramped off under damping (to avoid un-necessarily kicking the optics when disconnecting cables) and then the suspension watchdogs were shutdown for the duration of the measurement.
I used an LCR meter to measure R and L - as prescribed by Koji, the probe leads were shorted and the readback nulled to return 0. Then for R, I corroborated the values measured with the LCR meter against a Fluke DMM (they turned out to be within +/- 0.5 ohms of the value reported by the BK Precision LCR meter which I think is reasonable).
Pin1-9 (UL) / R = 30.6Ω / L=3.23mH
Pin2-10 (LL) / R = 30.3Ω / L=3.24mH
Pin3-11 (UR) / R = 30.6Ω / L=3.25mH
Pin4-12 (LR) / R = 31.8Ω / L=3.22mH
Pin5-13 (SD) / R = 30.0Ω / L=3.25mH
Pin1-9 (UL) / R = 31.7Ω / L=3.29mH
Pin2-10 (LL) / R = 29.7Ω / L=3.26mH
Pin3-11 (UR) / R = 29.8Ω / L=3.30mH
Pin4-12 (LR) / R = 29.7Ω / L=3.27mH
Pin5-13 (SD) / R = 29.0Ω / L=3.24mH
On the basis of this measurement, I see no problems with the OSEM actuators - the wire resistances to the flange seem comparable to the nominal OSEM resistance of ~13 ohms, but this isn't outrageous I guess. But I don't know how to reconcile this with Koji's measurement at the flange - I guess I can't definitively rule out the wire resistance being 30 ohms and the OSEMs being ~1 ohm as Koji measured. How to reconcile this with the funky PRM actuator measurement? Possibilities, the way I see it, are:
I want to measure the spot positions on the IMC mirrors. We know that they can't be too far off centerBasically I did the bare minimum to get these scripts in /opt/rtcds/caltech/c1/scripts/ASS/MC/ running on rossa (python3 mainly). I confirmed that I get some kind of spot measurement from this, but not sure of the data quality / calibration to convert the demodulated response into mm of decentering on the MC mirrors. Perhaps it's something the MC suspension team can look into - seems implausible to me that we are off by 5mm in PIT and YAW on MC2? The spot positions I get are (in mm from the center):
MC1 P MC2P MC3P MC1Y MC2Y MC3Y
0.640515 -5.149050 0.476649 -0.279035 5.715120 -2.901459
A future iteration of the script should also truncate the number of significant figures per a reasonable statistical error estimation.
I think the only part missing for assembly now are 4 2U chassis. The PA95s need to be soldered on as well (they didn't arrive in time to send to SC). The stuffed boards are stored under my desk. I inspected one board, looks fine, but of course we will need to run some actual bench tests to be sure.
I suppose you've tried doing the submatrix approach, where SIDE is excluded for the face DoFs? Does that give a better matrix? To me, it's unreasonable that the side OSEM senses POS motion more than any single face OSEM, as your matrix suggests (indeed the old one does too). If/when we vent, we can try positioning the OSEMs better.
For this technique to work, (i) the WFS loops must be well tuned and (ii) the beam must be well centered on MC2. I am reasonably certain neither is true. For MC2 coil balancing, you can use a HeNe, there is already one on the table (not powered), and I guess you can use the MC2 trans QPD as a sensor, MC won't need to be locked so you can temporarily hijack that QPD (please don't move anything on the table unless you're confident of recovering everything, it should be possible to do all of this with an additional steering mirror you can install and then remove once your test is done). Then you can do any variant of the techniques available once you have an optical lever, e.g. single coil drive, pringle mode drive etc to do the balancing.
I think Hang had some technique he tried recently as well, maybe that is an improvement.
I repeated the usual whitening board characterization test of:
Attachment #1 suggests that the steps are equal (3dB) in size, but note that the "Q" channel shows only ~half the response of the I channel. The drive is derived from a channel of an unused AI+dewhite board in 1Y2, split with a BNC Tee, and fed to the two inputs on the whitening filter. The impedance is expected to be the same on each channel, and so each channel should see the same signal, but I see a large asymmetry. All of this checked out a couple of weeks ago (since we saw ellipses and not circles) so not sure what changed in the meantime, or if this is symptomatic of some deeper problem.
Usually, doing this and then restoring the cabling returns the signal levels of REFL55 to nominal levels. Today it did not - at the nominal whitening gain setting of +18dB flat gain, when the PRMI is fringing, the REFL55 inputs are frequently reporting ADC overflows. Needless to say, all my attempts today evening to transition the length control of the vertex from REFL165 to REFL55 failed.
I suppose we could try shifting the channels to (physical) Ch5 and Ch6 which were formerly used to digitize the ALS DFD outputs and are currently unused (from Ch3, Ch4) on this whitening filter and see if that improves the situation, but this will require a recompile of the RTCDS model and consequent CDS bootfest, which I'm not willing to undertake today. If anyone decides to do this test, let's also take the opportunity to debug the BIO switching for the delay line.
I spent some time investigating the PRM this evening, trying out some of the stuff we discussed in the meeting.
Basically, my finding tonight was that I could not improve (make the pringle mode actuation witnessed by the Oplev QPD smaller) by +/- perturbing the butterfly actuation with of 0.05%, 0.5% and 1% of PIT (I didn't try YAW, or other values of PIT, as none of these seemed to do any good). It seems highly unlikely that the existing coil gains (these come after the output matrix) and the actual coil/magnet pairs are so perfectly tuned, so there must be something wrong with my method. I'll try more combos tomorrow. Separately, I verified that the naive PIT (YAW) moves the optic mainly, i.e. to the eye), in PIT(YAW) as judged by the REFL spot on the camera and the readback of the Oplev QPD.
For this work, I made a few changes to filter banks:
I noticed that the filters/switch states/gains for LOCKIN1 and LOCKIN2 are not consistent within either PRM or BS suspension, or across suspensions. Several filter INs/OUTs were also disabled - something for the SUSdiag team to note, whenever this is scripted, the script should check that the signal is indeed making it end-to-end.
In these results, can you also include the new matrix and what the relative imbalances were?
We could not find problems with any individual piece of the REFL55 electronics chain, from photodiode to ADC. Nevertheless, the PRMI fringes witnessed by REFL55 is ~x10 higher than ~two weeks ago, when the PRMI could be repeatably and reliably locked using REFL55 signals (ETMs misaligned).
Discussion and next steps:
Q: Koji asked me what is the problem with this apparent increased optical gain - can't we just compensate by decreasing the whitening gain?
A: I am unable to transition control of the PRMI (no ETMs) from 3f to 1f, even after reducing the whitening gain on the REFL55 channels to prevent the saturation. So I think we need to get to the bottom of whatever the problem is here.
Q: Why do we need to transfer the control of the vertex to the 1f signals at all?
A: I haven't got a plot in the elog, but from when I had the PRFPMI locked last year, the DARM noise between 100-1kHz had high coherence with the MICH control signal. I tried some feedforward to try and cancel it but never got anywhere. It isn't a quantitative statement but the 1f signals are expected to be cleaner?
Koji pointed out that the MICH signal is visible in the REFL55 channels even when the PRM is misaligned, so I'm gonna look back at the trend data to see if I can identify when this apparent increase in the signal levels occurred and if I can identify some event in the lab that caused it. We also discussed using the ratio of MICH signals in REFL and AS to better estimate the losses in the REFL path - the Faraday losses in particular are a total unknown, but in the AS path, there is less uncertainty since we know the SRM transmission quite precisely, and I guess the 6 output steering mirrors can be assumed to be R=99%.
From the last failure, I had ordered 2 extra capacitors (they are placed on top of the PSL enclosure above where the capacitors would normally be installed). If the new capacitors lasted < 6months, may be symptomatic of some deeper problem though, e.g. the HEPA fans themselves need replacing. We don't really have a good diagnostic of when the failure happened I guess as we don't have any channel recording the state of the fans.
I think the PSL HEPA (both 2 units) are not running. The switches were on. And the variac was changed from 60% to 0%~100% a few times but no success.
I have no troubleshooting power anymore today. The main HEPA switch was turned off.
How should I try to understand why PIT and YAW are so different?
I wanted to put my optomechanical instability hypothesis to the test. So I decided to cut the input power to the IMC by ~half and try locking the PRFPMI. However, this did not improve the stability of the buildup in the arm cavities, while the control was solely on the ALS error signal.
Basically, with some tweaks to loop gains, it worked, see Attachment #1. Note that the lower right axis shows the IMC transmission and is ~7500 cts, vs the nominal ~15,000 cts.
Cutting the input power did not have the effect I hoped it would. Basically, I was hoping to zero the optical CARM offset while the IFO was entirely under ALS control, and have the arm transmission be stable (or at least, stay in the linear regime of REFL11). However, the observation was that the IFO did the usual "buzzing" in and out of the linear regime. Right now, this is not at all a problem - once the IR error signal is blended in, and DC control authority is transferred to that signal, the lock acquisition can proceed just fine. And I guess it is cool that we can lock the IFO at ~half the input power, something to keep in mind when we have the remote controlled waveplate, maybe we always want to lock at the lowest power possible such that optomechanical transients are not a problem.
I also don't think this test directly disputes my claim that the residual CARM noise when the arm cavities are under purely ALS control is smaller than the CARM linewidth.
What does this mean for my hypothesis? I still think it is valid, maybe the power has to be cut even further for the optomechanics to not be a problem. In Finesse (see Attachment #2), with 0.3 W input power to the back of the PRM, and with best guesses for the 40m optical losses in the PRC and arms, I still see that considerable phase can be eaten up due to the optomechanical resonance around ~100 Hz, which is where the digital CARM loop UGF is. So I guess it isn't entirely unreasonable that the instability didn't go away?
After this work, I undid all the changes I made for the low power lock test. I confirmed that IMC locking, POX/POY locking, and the dither alignment systems all function as expected after I reverted the system.
Since it seems like the entire electronics chain has no obvious failure, I decided to compensate for the apparent increased optical gain by turning the flat whitening gain down from +18dB to 0dB. Then, after some fiddling around with alignment, settings etc, I was able to lock the PRMI once again, with the ETMs misaligned, using REFL55_I to sense PRCL, and REFL55_Q to sense MICH. Some sensing matrices attached. Some notes:
So there is clearly something funky with the nominal MICH actuation scheme (MICH suspension, PRM suspension or both), which we should get to the bottom of before trying any low noise locking. I think using the ITMs as the MICH actuator in the full lock will not be a good low nosie strategy, as we would then be "polluting" all our suspended optics with our control loops, which seems highly suboptimal for technical noise sources like coil driver noise etc.
I spent an hour today evening checking out the remote waveplate operation. Basic remote operation was established 👍 . To run a test on the main beam (or any beam for that matter), we need to lay out some long cabling, and install the controller in a rack. I will work with Jordan in the coming days to do these things. Apart from the hardware, some EPICS channel will need to be added to the c1ioo.db file and a python script will need to be set up as a service to allow remote operation.
Satisfied that the unit works basically as expected, I decided to stop for today. My thinking was that we can have the ESP300 installed in 1X1 or 1X2 (depending on where space is more readily available). I will upload have uploaded a cartoon here so people can comment if they like/dislike my plan.
Once everything is installed, we can run some tests to see if the rotary motion disturbs the PSL in any meaningful way. I will upload some photos to the picasa later. Photos here.
I spent some time today setting up a workable user interface to control the waveplate.
So this system is ready to be installed once Jordan and I find some time to lay out cabling + install the ESP300 controller in a rack.
At the moment, there is no high power and there is minimal risk of damaging anything, but someone should double check my logic to make sure that we aren't gonna burn the precious IFO optics. We should also probably hook up a hardware interlock to this controller.
I went through some aLIGO documentation and believe that they are using a custom made potentiometer based angle sensor rather than the integrated Newport (or similar) sensor+motor. My reading of the situation was that there were several problems to do with hysterisis, the "find home" routine etc. I guess for our purposes, none of these are real problems, as long as we are careful not to randomly rotate the waveplate through a full 180 degrees and go through the full fringe in the process. Need to think of a clever way to guard against careless / accidental MEDM button presses / slider drags.
Unrelated to this work: I haven't been in the lab for ~a week so I took the opportunity today to go through the various configs (POX/POY/PRMI resonant carrier etc). I didn't make a noise budget for each config but at least they can be locked 👍 . I also re-aligned the badly misaligned PMC and offloaded the somewhat large DC WFS offsets (~100 cts, which I estimate to be ~150 nNm of torque, corresponding to ~50 urad of misalignment) to the IMC suspensions' slow bias voltages.
We (rana, yehonathan and i) briefly talked about having high power going into the IFO. I worked on some calcs a couple of years ago, that are summarized here. There is some discussion in the linked page about how much power we even need. In summary, if we can have
then we can have an overall gain of ~2400 from laser to each arm cavity (since the BS divides the power equally between the two arms). The easiest place to get some improvement is to improve T_IMC * T_inputFaraday. If we can get that up to ~90%, then we can have an overall gain of ~4000, which is I think the limit of what is possible with what we have.
We also talked about the EOM. At the same time, I had also looked into the damage threshold as well as clipping losses associated with the finite aperture of our EOM, which is a NewFocus 4064 (KTP is the Pockel medium). The results are summarized in Attachments #1 and #2 respectively. Rana thinks the EOM can handle factor of ~3 greater power than the rated damage threshold of 20W/mm^2.
Once again, I found the door to the outside in the control room open when I came in ~1215pm. I closed it.
The C1:IFO-STATE variable is actually a bunch (16 to be precise) of bits, and the byte they form (2 bytes) converted to decimal is what is written to the EPICS channel. It was reported on the call today that the nominal value of the variable when the IMC is locked was "8", while it has become "10" today. In fact, this has nothing to do with the IMC. You can see that the "PMC locked" bit is set in Attachment #1. This is done in the AutoLock.sh PMC autolocker script, which was run a few days ago. Nominally, I just lock the PMC by moving some sliders, and I neglect to set/unset this bit.
Basically, there is no anomalous behavior. This is not to say that the situation cannot be improved. Indeed, we should get rid of the obsolete states (e.g. FSS Locked, MZ locked), and add some other states like "PRMI locked". While there is nothing wrong with setting these bits at the end of execution of some script, a better way would be to configure the EPICS record to automatically set / unset itself based on some diagnostic channels. For example, the "PMC locked" bit should be set if (i) the PMC REFL is < 0.1 AND (ii) PMC TRANS is >0.65 (the exact thresholds are up for debate). Then we are truly recording the state of the IFO and not relying on some script to write to the bit (I haven't thoguht through if there are some edge cases where we need an unreasonable number of diagnostic channels to determine if we are in a certain state or not).
A couple of years ago, I got some info about the amplifier setup at the sites from Terra - sharing here in case there is some useful info in there (our setup will be rather different, but it looked to me like our Amp is a 2017 vintage and it may be that the performance is not the same as reported in the 2019 paper).
collection of docs (table layout in 'Proposed....setup') : https://dcc.ligo.org/LIGO-T1700046
LVC 70W presentation: https://dcc.ligo.org/LIGO-G1800538
I guess we should double check that the beam size everywhere (in vacuum and on the PSL table) is such that we don't exceed any damage thresholds for the mirrors used.
I've occcupied the southernmost electronics bench for assembling the 4 production version HV coil driver chassis. I estimate it will take me 3 days, and have left a sign indicating as much. Once the chassis assembly is done, I will need to occupy the northernmost bench where bench supplies are to run some functionality tests / noise measurements, and so unless there are objections, I will move the Acromag box which has been sitting there.
We did the following this afternoon.
The IMC stayed locked throughout our work, and judging by the CDS overview screen, we don't seem to have done any lasting damage, but I will run more tests. Note that the waveplate isn't yet installed in the beam path - I may do this later today evening depending on lab activity, but for now, it is just sitting on the lower shelf inside the PSL enclosure. I will post some photos later.
Update: The waveplate was installed. I gave it a couple of rounds of cleaning by first contact, and visually, it looked good to me. More photos uploaded. I also made some minor improvements to the MEDM screen, and setup the communication script with the ESP300 to run as a systemd service on c1psl. Let's see how stable things are... I think the philosophy at the sites is to calibrate the waveplate rotation angle in terms of power units, but i'm not sure how the unit we have performs in terms of backlash error. We can do a trial by requesting ~100 "random" angles, monitoring the power in s- and p-polatizations, and then quanitfying the error between requested and realized angles, but I haven't done this yet. I also haven't added these channels to the set recorded to frames / to the burt snapshot - do we want to record these channels long term?
The MC / WFS stability seemed off to me. Trending some channels at random, I saw that the MC3 PIT/YAW gains were restored mixed up (PIT was restored to YAW and vice versa) in the last day sometime - I wasn't sure what other settings are off so I did a global burtrestore from the last time I had the interferometer locked since those were settings that at least allow locking (I am not claiming they are optimal).
How are these settings being restored after the suspension optimization? If the burtrestore is randomly mixing up channels, seems like something we should be worried about and look into. I guess it'd also be helpful to make sure we are recording snapshots of all the channels we are changing - I'm not sure if the .req file gets updated automatically / if it really records every EPICS record. It'd be painful to lose some setting because it isn't recorded.
Unconnected to this work - the lights in the BS/PRM chamber were ON, so I turned them OFF. Also unconnected to this work, the summary pages job that updates the "live" plots every half hour seem to be dead again. There is a separate job whose real purpose is to wait for the data from EOD to be transferred to LDAS before filling in the last couple of hours of timeseries data, but seems to me like that is what is covering the entire day now.
This is to facilitate running of scripts like the CDS reboot script, mx_stream restart, etc, from rossa, without being pwd prompted every time, whereas previously it was only possible from pianosa. I added the public key of rossa to FB and the RT FE servers. I suppose I could add it to the Acromag servers too, but I haven't yet.
I was a bit surprised by these numbers suggesting the PMC transmission is only 50-60%. I went to the table today and confirmed that it is more like 85% (1.3 W in, 1.1 W transmitted, both numbers from with the FieldMate power meter), as I claimed in 2019. Even being conservative with the power meter errors, I think we can be confident T_PMC will be >80% (modulo any thermal effects with higher power degrading the MM). There isn't any reliable record of what the specs of the PMC mirrors are, but assuming the IO couplers have T=4000ppm and the end mirror has T=500ppm as per Alan's plot, this is consistent with a loss of something like 300ppm loss per mirror - seems very high given the small beam spots, but maybe these mirrors just aren't as high quality as the test masses?
It's kind of unfortunate that we will lose ~20% of the amplifier output through the first filter, but I don't see an easy way to clean these mirrors. It's also not clear to me if there is anything to be gained by attempting a cleaning - isn't the inside of the cavity supposed to be completely isolated from the outside? Maybe some epoxy vaporization events degraded the loss?
The transmitted power was ~50-60 mW. (Had to use power meter suspended by hand only.
Indeed, you can make your own snapshot by specifying the channels to snap in a .req file. But what I meant was, we should confirm that all the channels that we modify are already in the existing snapshot files in the autoburt dir. If it isn't, we should consider adding it. I think the whole burt system needs some cleaning up - a single day of burt snapshots occupies ~400MB (!) of disk space, but I think we're recording a ton of channels which don't exist anymore. One day...
Your message suggests that we can set burt to start noticing channel changes at home point and create a .req file that can be used to restore later. We'll try to learn how to do that. Right now, we only know how to burt restore using the existing snapshots from the autoburt directory, but they touch more things than we work on, I think. Or can we just always burt restore it to morning time? If yes, what snapshot files should we use?
I will upload some plots later - but in summary, I set the HEPA speed to ~40%. I used (i)IMC transmission RIN, (ii) Arm cavity transmission RIN and (iii) ALS beat noise as 3 diagnostics, to see how noise in various frequency bands for these signals change as a function of the HEPA speed. The MC2T RIN shows elevated noise between 1-10Hz at even the lowest speed I tried, ~20% of the max on each blower. The elevated noise extended to ~50-70 Hz for HEPA speeds >40% of the maximum, and the arm cavity RIN and ALS signals also start to become noisy for speeds >60% of the maximum. So I think 40% is a fine speed to run at - for squeezing measurement we may have to turn off the HEPA for 10mins but for the usual single arm / PRMI / DRMI locking, this should be just fine. For the elevated ALS noise - I'm not sure if the coupling is happening over the top of the enclosure where the fiber bringing light from EX comes close to the HEPA filters, or if it is happening inside the PSL enclosure itself, near the beat mouth - but anyways, at the 40% speed, I don't see any effect on the ALS noise.
I checked with a particle counter at the SW corner of the PSL table (which is the furthest away we can be on the table from the HEPA blowers) after leaving the blowers on for ~30mins and it registered 0 for both 0.3um and 0.5um sized particles (if the blowers are off, the respective numbers are 43 and 9 but I forgot what the units were, and I believe they have to be multiplied by 10).
I have not yet marked the speed control units yet in case there is some other HEPA science that needs to be done before deciding what is the correct setting. But I think I can get the PRFPMI lock without much issue with this lower speed, which is what I will try later today evening.
The problem here was that the RFM errors cropped up again - seems like it started ~4am today morning judging by TRX trends. Of course without the triggering signal the arm cavity couldn't lock. I rebooted everything (since just restarting the rfm senders/receivers did not do the trick), now arm locking works fine again. It's a bit disappointing that the Rogue Master setting did not eliminate this problem completely, but oh well...
It's kind of cool that in this trend view of the TRX signal, you can see the drift of the ETMX suspension. The days are getting hot again and the temp at EX can fluctuate by >12C between day and night (so the "air-conditioning" doesn't condition that much I guess 😂 ), and I think that's what drives the drift (idk what the transfer function to the inside of the vacuum chamber is but such a large swing isn't great in any case). Not plotted here but i hypothesize TRY levels will be more constant over the day (modulo TT drift which affects both arms).
The IMC suspension team should double check their filters are on again. I am not familiar with the settings and I don't think they've been added to the SDF.
This is the actuator calibration. For the error point calibration, you have to look at the filter in the calibration model. I think it's something like 8e-13m/ct for POX and similar for POY.
I calibrated the control arms signals by 2.44 nm/cts calibration factor directly picked up from 13984.
The SDF system is supposed to help with restoring the correct settings, complementary to burt. My personal opinion is that there is no need to commit these filters to SDF until we're convinced that they help with the locking / noise performance.
I double checked today and the F2A filters in the output matrices of MC1, MC2 and MC3 in the POS column are ON. I do not get what SDF means? Did we need to add these filters elsewhere
The NPRO has been off since ~1AM this morning it looks like. Is this intentional? Can I turn it back on (or at least try to)? The interlock signal we are recording doesn't report getting tripped but I think this has been the case in the past too.
After getting the go ahead from Koji, I turned the NPRO back on, following the usual procedure of diode current ramping. PMC and IMC locked. Let's see if this was a one-off or something chronic.
I want to work on the IFO this weekend, so I reverted the IMC suspension settings just now to what I know work (until the new settings are shown quantitatively to be superior). There isn't any instruction here on how to upload the new settings, so after my work, I will just restore from a burt-snapshot from before I changed settings.
In the process, I found something odd in the MC2 coil output filter banks. Attachment #1 shows what it it is today. This weird undetermined state of FM9 isn't great - I guess this flew under the radar because there isn't really any POS actuation on MC2. Where did the gain1 filter I installed go? Some foton filter file corruption? Eventually, we should migrate FM7,FM8-->FM9,FM10 but this isn't on my scope of things to do for today so I am just putting the gain1 filter back so as to have a clean FM9 switched on.
The old setting can be restored by running python3 /users/anchal/20210505_IMC_Tuned_SUS_with_Gains/restoreOldConfigIMC.py from allegra or donatella.
I wrote the values from the c1mcs burt snapshot from ~1400 Saturday May 15, at ~1600 Sunday May 16. I believe this undoes all my changes to the IMC suspension settings.
I was preparing a short write-up / test procedure for the custom HV coil driver, when I thought of something I can't resolve. I'm probably missing some really basic physics here - but why do we not account for the shot noise from DC current flowing through the series resistor? For a 4kohm resistor, the Johnson current noise is ~2pA/rtHz. This is the target we were trying to beat with our custom designed HV bias circuit. But if there is a 1 mA DC current flowing through this resistor, the shot noise of this current is 18pA/rtHz, which is ~9 times larger than the Johnson noise of the same resistor. One could question the applicability of this formula to calculate the shot noise of a DC current through a wire-wound resistor - e.g. maybe the electron transport is not really "ballistic", and so the assumption that the electrons transported through it are independent and non-interacting isn't valid. There are some modified formulae for the shot noise through a metal resistor, which evaluates to 10pA/rtHz for the same 4kohm resistor, which is still ~5x the Johnson noise.
In the case of the HV coil driver circuit, the passive filtering stage I added at the output to filter out the excess PA95 noise unwittingly helps us - the pole at ~0.7 Hz filters the shot noise (but not the Johnson noise) such that at ~10 Hz, the Johnson noise does indeed dominate the total contribution. So, for this circuit, I think we don't have to worry about some un-budgeted noise. However, I am concerned about the fast actuation path - we were all along assuming that this path would be dominated by the Johnson noise of the 4kohm series resistor. But if we need even 1mA of current to null some DC DARM drift, then we'd have the shot noise contribution become comparable, or even dominant?
I looked through the iLIGO literature, where single-stage suspensions were being used, e.g. Rana's manifesto, but I cannot find any mention of shot noise due to DC current, so probably there is a simple explanation why - but it eludes me, at least for the moment. The iLIGO coil drivers did not have a passive filter at the output of the coil driver circuit (at least, not till this work), and there isn't any feedback gain for the DARM loop at >100 Hz (where we hope to measure squeezing) to significantly squash this noise.
Attachment #1 shows schematic topologies of the iLIGO and proposed 40m configs. It may be that I have completely misunderstood the iLIGO config and what I've drawn there is wrong. Since we are mainly interested in the noise from the resistor, I've assumed everything upstream of the final op-amp is noiseless (equivalently, we assume we can sufficiently pre-filter these noises).
Attachment #2 shows the relative magnitudes of shot noise due to a DC current, and thermal noise of the series resistor, as a function of frequency, for a few representative currents, for the slow bias path assuming a 0.7Hz corner from the 4kohm/3uF RC filter at the output of the PA95.
Some lit review suggests that it's actually pretty hard to measure shot noise in a resistor - so I'm guessing that's what it is, the mean free path of electrons is short compared to the length of the resistor such that the assumption that electrons arrive independently and randomly isn't valid. So Ohm's law dictates and that's what sets the current noise. See, for example, pg 432 of Horowitz and Hill.
Since the repair work, the temperature is significantly cooler. Surprisingly, even at the vertex (to be more specific, inside the PSL enclosure, which for the time being is the only place where we have a logged temperature sensor, but this is not attributable to any change in the HEPA speed), the temperature is a good 3 deg C cooler than it was before the HVAC work (even though Koji's wind vane suggest the vents at the vertex were working). The setpoint for the entire lab was modified? What should the setpoint even be?
- I went to the south arm. There are two big vent ducts for the outlets and intakes. Both are not flowing the air.
The current temp at 7pm was ~30degC. Max and min were 31degC and 18degC.
- Then I went to the vertex and the east arm. The outlets and intakes are flowing.
we decided to give the PRFPMI lock a go early-ish. Summary of findings today eve:
The ALS--> IR CARM handoff is the problematic step. In the past, getting over this hump has just required some systematic loop TF measurements / gain slider readjustments. We will do this in the next few days. I don't think the ALS noise is any higher than it used to be, and I could do the direct handoff as recently as March, so probably something minor has changed.
I wanted to try hosting some docker images on a "private" server, so I installed Docker on nodus following the instructions here. The install seems to have succeeded, and as far as I can tell, none of the functionality of nodus has been disturbed (I can ssh in, access shared drive, elog seems to work fine etc). But if you find a problem, maybe this action is responsible. Note that nodus is running Scientific Linux 7.3 (Nitrogen).
Given that ETMX looks to be in good shape and the optic and suspension tower are ready for vacuum and air bakes respectively, I set about re-gluing the knocked off magnet of ETMY. In my previous elog, I had identified the knocked off magnet as the UL magnet. But in fact, it was the LR magnet that broke off. This is actually one of the magnets that was knocked off when Johannes was removing the optic from the vacuum chamber. I have edited the old elog accordingly.
Step 1: Removing epoxy residue
Step 2: Putting the optic in the magnet gluing jig
Step 3: Gluing the magnets
Provided the gluing goes well, the plan for tomorrow is:
The pickle pickers came off nicely and both magnets seem to be glued on okay. The alignment of the face magnets look pretty good, but we will only really know once we suspend the mirror, check the pitch balance, and put in the OSEM coils.
I brought the ETMY suspension tower + OSEM coils out of the vacuum chamber into the cleanroom. Given that the old wire had a pretty sharp kink in it, I removed it with the intention of suspending the optic with a new length of wire. I noticed a few potential problems:
Attachment #1 - ETMY tower is different from ETMX tower:
Attachment #2 - the base of the tower is significantly rusty:
I am holding off on attempting to re-suspend the optic for now, until we decide if the old wire grooves need to be removed or not. If we are okay with re-using the same piece as is, or if we are okay with using sandpaper and not the machine shop to remove the grooves, I will resume the re-suspension process.
Eric suggested another alternative, which is to use the old ETMX tower. I don't recall it being rusted, but this has to be checked again. The other problem of the wire-grooves would possibly still be an issue.
Regarding the vacuum bake of the ETMs, Bob tells us that the best case scenario we are looking at is September.
Rana felt it was alright to use the wire clamp and suspension cage in its existing condition for checking the ETMY magnet-OSEM coil alignment. So we set about trying to re-suspend ETMY. The summary of our attempts:
Regarding the vacuum bake of the optics: why do we want to do this again? Koji mentioned that the EP30-2 curing process does not require a bake, and there is also no mention of requiring a vacuum bake in the EP30-2 gluing guide. Is there any other reason for us to vacuum bake the optic?
Attachment #1: Striptool trace showing all OSEM coils have been pushed in till the PD readout is approximately half the fully open value
Attachment #2: Pitch balance is off by ~2.8mrad (the Iris center is 5.5" above the table)
Attachment #3: UR magnet
Attachment #4: UL magnet
Attachment #5: LR magnet
Attachment #6: LR magnet
Attachment #7: SD magnet
Just collecting some links from my elog searching today here for easy reference later.
I couldn't find any details of the actual measurement technique, though perhaps I just didn't look for the right keywords. But Koji's suggestion of measuring powers with the bi-directional coupler before the triple resonant circuit (but after the power combiner) should be straightforward.
it will connect to a 15 pin breakout board in the Acromag chassis
It's nice and compact, and the cost of new 15-pin DSUB cables shouldn't be a factor here. What does the 15p cable connect to?
Some years ago I bought some dividers from Wenzel. For each arm, we have x256 and a x64 divider. Wired in series, that means we can divide each IR beat by 2^14.
The highest frequency we can read in our digital system is ~8100 Hz. This corresponds to an RF frequency of ~132 MHz which as much as the BBPD could go, but less than the fiber PDs.
Today we checked them out:
Since this seems promising, we're going to make a box on Monday to package both of these. There will one SMA input and output per channel.
Each channel will have a an amplifier since this need not be a low noise channel. The ZKL-1R5 seems like a good choice to me. G=40 dB and +15 dBm output.
Then Gautam will make a frequency counter module in the RCG which can do counting with square waves and not care about the wiggles in the waveform.
I think this ought to do the trick for our Coarse frequency discriminator. Then our Delay Box ought to be able to have a few MHz range and do all of the Fast ALS Carm that we need.
Earlier today, we did a bunch of stuff to see if we could improve the situation with the excess ALS-X noise. Long story short, here are the parameters that were changed, and their initial and final values:
X-end laser diode temperature: 28.5 degrees ---> 31.3 degrees
X-end laser diode current: 1.900 A ---> 1.942 A
X-end laser crystal temperature: 47.43 degrees ---> 42.6 degrees
PSL crystal temperature: 33.43 degrees ---> 29.41 degrees
PSL Diode A temperature: 21.52 degrees ---> 20.75 degrees
PSL Diode B temperature: 22.04 degrees ---> 21.3 degrees
The Y-end laser temperature has not yet been adjusted - this will have to be done to find the Y-beatnote.
Unfortunately, this does not seem to have fixed the problem - I was able to find the beatnote, with amplitude on the network analyzer in the control room consistent with what we've been seeing over the last few days, but as is clear from Attachment 1, the problem persists...
Some details not directly related to this work:
I built a Simulink model of the magnetic levitation system and try to explain the dip in the open-loop transfer function that was observed.
One can download the model in the svn. The corresponding block diagram is shown by the figure below.
Here "Magnet" is equal to inverse of the magnet mass. Integrator "1/s" gives the velocity of the magnet. A further integrator gives the displacement of the magnet.
Different from the free-mass response, the response of the magnet is modified due to the existence of the Eddy-current damping and negative spring in the vertical
direction, as indicated by the feedback loops after two integrals respectively. The motion of the magnet will change the magnetic field strength which in turn will pick
up by the Hall-effect sensor. Unlike the usual case, here the Hall sensor also picks up the magnetic field created by the coil as indicated by the loop below the mechanical
part. This is actually the origin of the dip in the open-loop transfer function. In the figure below, we show the open-loop transfer function and its phase contributed by both
the mechanical motion of the magnet and the Hall sensor with the black curve "Total". The contribution from the mechanical motion alone is shown by the magenta curve
"Mech" which is obtained by disconnecting the Hall sensor loop (I rescale the total gain to fit the measurement data due to uncertainties in those gains indicated in the figure).
The contribution from the Hall sensor alone is indicated by the blue curve "Hall" which is obtained by disconnecting the mechanical motion loop. Those two contributions
have the different sign as shown by the phase plot, and they destructively interfere with each other and create the dip in the open-loop transfer function.
In the following figure, we show the close-loop response function of the mechanical motion of the magnet.
As we can see, even though the entire close loop of the circuit is stable, the mechanical motion is unstable around 10 Hz. This simply comes from the fact that
around this frequency, the Hall sensor almost has no response to the mechanical motion due to destructive interference as mentioned.
In the future, we will replace the Hall sensor with an optical one to get rid of this undesired destructive interference.
differentiator from 10 Hz to 50 Hz, we increase the phase margin and the resulting
magnetic levitation system is stable even without the help of eddy-current damping.
The new block diagram for the system is the following:
Here the eddy-current damping component is removed and we add an additional differential
circuit with an operational amplifier OP27G.
In addition, we place the Hall sensor below the magnet to minimize the coupling between
the coil and the Hall sensor.
The resulting levitation system is shown by the figure below: