it would be a good idea for us to have an auto-reminder to have us check the flow of all the HEPAs in the lab and elog it once a year so that we can replace filters and pre-filters appropriately.

what is the noise level before the HV stage? i.e. how well is the acromag noise being filtered?

For the input matrix diagonalization, it seemed to me that when we had a significant seismic event or a re-alignment of the optic with the bias sliders, the input matrix also changes.

Meaning that our half-light voltage may not correspond to the half point inside the LED beam, but that rather we may be putting the magnet into a partially occluding state. It would be good to check this out by moving the bias to another setting and doing the ringdown there.

true. also try to choose a cap with a goow high frequency response. In the Electronics Noise book by Ott there's some graph about this. I bet you good do a Bing search and also find something more modern. Basically we want to make sure that the self resonance is not happening at low frequencies. Might be tought to find one with a good HF response, a high voltage rating, and > 1uF.

yes, both problems can be fixed. Usually we just order some spare lead-acid batteries from SRS (Steve may have some spare ones somewhere). The DC offset often comes from a busted FET input. I bought 50 of those at one point - they're obsolete. Its also possible to replace the input stage with any old FET pair.

I'll handle the one with the offset if you leave it on my desk.

I don't think your simulation looked inaccurate (at least not to me). In my opinion, we just want to minimize any excess noise from intermodulation. Of course, its possible that stuffing too many notches will make it difficult to have the same low noise as a simple circuit, so that's worth considering.

Also, the intermodulation is mainly a problem when the other peaks are not suppressed by some feedback: e.g. POP55_I can have excess noise if POP55_Q or POP11_I are not controlled by some MICH/PRCL/SRCL loops.

For the WFS, perhaps this is not a significant issue, but I'm not sure. My suggestion is to stuff 11 & 55 for sure, and then the others depending on the amplitude of the peaks and the consequent intermodulation. IF it works with all stuffed, that seems good. If its tricky to get it to work with all stuffed, I'd back off on a couple of them...but it probably takes more careful thought to figure out which ones are least important.

looks good to me.

The thing I usually look for is how much the downstream system (mixers, etc) can perturb the main oscillator. i.e. we don't want mixer in one chain to reflect back and disturb the EOM chain. But since our demods have amplifiers on the LO side we're pretty immune to that.

Cool. Can you give us Bode plots of the open loop gain for each of the 5 length control loops?

• looking better, but the CARM plot still looks weird.
• you should plot from 0.01 - 10,000 Hz
• All of the loops should have true integrators below 1 Hz.
• I don't think these loops are stable; the Bode plot is not a good way to check stability for LTI systems since you can be fooled by phase wrapping.

I expect that a single OSEM channel can't be better than 1e-10 m/rHz above 5 Hz, so probably something wrong in the calibration. 1.6 V/mm seems right to me, so could be some place else.

I would:

1. look at the free swingin michelson. Should be able tu null that siggnal in all ports to define the Q phase.
2. If things are weird, put an RF signal nto the demod board mhich is offset from the LO by ~100 Hz and verify the demod/whitening chain is kosher.
3. Lock PRMI and drive lines > 200 Hz. If PRC/MICH are not orthogonal, then there may be a mis tuning of RF SB wavelength and cavity lengths.
4. IF PRMI is sort of healthy, we could be having a weird SB resonance in the arms.

I'm curious to see if the demod phase for MICH in REFL & AS chamges between thi simple Mcihelson and PRMI. IF there's a change, it could point to a PRCL/f2 mismatch.

But I would still bet on demod chain funniness.

agreed, seems excessive. I always prefer bandstop over notch in case the eigenfrequency wanders, but the bandstop could be made to be just a few Hz wide.

Herewith, I describe an adventure

1. Balance the OSEM input matrix using the free swinging data (see prev elogs).
2. Balance the coil actuation by changing the digital coil gains. This should be done above 10 Hz using optical levers, or some IMC readout (like the WFS). At the end of this process, you should put a pringle vector into the column of the SUS output matrix that corresponds to one of the SUS OSC/LOCKIN screens. Verily, the pringle excitation should produce no signal in MC_F or da WFS.
3. use the Malik doc on the single suspension to design feed-forward filters for the SUS COIL filter banks. You can get the physical parameters using the design documents on DCC / 40m wiki and then modify them a bit based on the eigenfrequencies in the free swinging data.
4. Model the 2x2 system which includes longitudinal and pitch motion. Consider how accurate the filters must be to maintain a cross-coupling of < 3% in the 0.5-2 Hz band.
5. Is this decoupling forsooth still maintained when you close the SUS damping loops in the model? If not, why so?
6. Make step response measurements of the damping loops and record/plot data. Use physical units of um/urad for the y-axes. How much is the step response cross-coupling?
7. Consider the IMC noise budget: are the low pass filters in the damping loops low-passing enough? How much damping is demasiado (considering the CMRR of the concrete slab for seismic waves)?
8. Can we use Radhika's AAA representation to auto-tune the FF and damping filters? It would be very slick to be able to do this with one button click.

gautam: For those like me who don't know what the AAA representation is: the original algorithm is here, and Lee claims his implementation of it in IIRrational is better, see his slides.

there were a zillion processes trying to activate (this is the initial activation after the initial installation) matlab 2015b on megatron, so I killed them all. Was someone logged in to megatron and trying to run matlab sometime in 2020? If so, speak now, or I will send the out-of-control process brute squad after you!

ugh. sounds bad - maybe a short. I suggest measuring the inductance; thats usually a clearer measurement of coil health

I installed QTgrace using yum on donatella. Both Grace and XMgrace are broken due to some boring fight between the Fedora package maintainers and the (non existent) Grace support team. So I have symlinked it:

controls@donatella|bin> sudo mv xmgrace xmgrace_bak
controls@donatella|bin> sudo ln -s qtgrace xmgrace
controls@donatella|bin> pwd
/usr/bin

I checked that dataviewer works now for realtime and playback. Although the middle click paste on the mouse doesn't work yet.

I think this is probably due to the safety tour yesterday. I beleive Jordan showed them around the office area and C&B. Not sure why they left through the control room.

Good Enough! Let's move on with output matrix tuning. I will talk to you guys about it privately so that the whole doesn't learn our secret, and highly sought after, actuation balancing.

I suspect that changing the DC alignment of the SUS changes the required input/output matrix (since changes in the magnet position w.r.t. the OSEM head change the sensing cross-coupling and the actuation gain), so we want to make sure wo do all this with the mirror at the correct alignment.

• Locked PRMI several tmes after Gautam setup. Easy w IFO CONFIG screen
• tuned up alignment
• Still POP22_I doesn't go above ~111, so not triggering the loops. Lowered triggers to 100 (POP22 units) and it locks fine now.
• Ran update on zita, and now it lost its mounts (and maybe its mind). Zita needs some love to recover the StripTool plots 
• Put the $600 ebay TDS3052 near the LSC rack and tried to look at the RF power, but found lots of confusing information. Is there really a RF monitor in this demod board or was it disconnected by a crazy Koji ? I couldn't see any signal above a few mV.
• Put a 20 dB coupler in line with the RF input and saw zip. Then I put the RF signal directly into the scope and saw that the 55 MHz signal is ~30 mVpp into 50 Ohms. I waited a few minutes with triggering to make sure I was getting the largest flashes. Why is the optical/RF signal so puny? This is ~100x smaller than I think we want...its OK to saturate the RF stuff a little during lock acquisition as long as the loop can suppress it so that the RMS is < 3 dBm in the steady state.

When we're debugging our RF system, either due to weird demod phases, or low SNR, or non-stationary noise in the PDH signals, its good to have some baseline measurements of the RF levels in the lab.

I got this cheap USB dongle (RTL-SDR.COM) that seems to be capable of this and also has a bunch of open source code on GitHub to support it. It also comes mith an SMA coax and rabbit ear antenna with a flexi-tripod.

I used CubicSDR, which has free .dmg downloads for MacOS.It would be cool to have a student write some python code (perhaps starting with RTL_Power) for this to let us hop between the diffierent RF frequencies we care about and monitor the power in a small band around them.

There's an integrator in the MC WFS servos, so you should never be disabling the ASC inputs in the suspensions. Disabling 1 leg in a 6 DOF MIMO system is like a kitchen table with 1 leg removed.

Just diagnose your suspension stuff with the cavity unlocked. You should be able to see the effect by characterizing the damping loops / cross-coupling.

I think there's been some mis-communication. There's no updated Hang procedure, but there is the one that Anchal, Paco and I discussed, which is different from what is in the elog.

We'll discuss again, and try to get it right, but no need to make multiple forks yet.

convergence is great.

Next we wanna get the F2A filters made since most of the IMC control happens at f < 3 Hz. Once you have the SUS state space model, you should be able to see how this can be done using only the free'swinging eigenfrequencies. Then you should get the closed loop model including the F2A filters and the damping filters to see what the closed loop behavior is like.

I think I mis-spoke about the balancing channels before. The ~20 Hz balancing could go into either the COIL banks or the SUS output matrix.

I believe its more conceptually clean to do this as gains in the outputmatrix, and leave the coil gains as +/- 1. i.e. we would only use the coil gains to compensate for coil/magnet actuation strength.

Then the high frequency balance goes into the outputmatrix. The F2A and A2L decoupling filters would then be generated having a high frequency gain = 1.

Force to Angle. It just means the filters that are in the POS OUTPUT matrix. I think in the past sometimes they are called F2P or F2A.

These filters account for the frequency dependent coupling of the DOFs around the suspension resonance. Take a look at what Bhavini is doing for the plots.

Maybe tighten the tensioner on the door closer so that it closes by itself even in the low velocity case. Or maybe just use the front door like everyone else?

found it unresponsive. Restarted fine using procedure documented in wiki

Looks mostly right, but you used the OSEM sensors as readbacks. We are diagonalizing using the cavity sensors. Using the diagonalized input matrix is also good since that will reduce the cross-coupling due to the damping loops.

Its sort of a subtle issue:

1. The sensors are are diagonalized into the eigenmode basis, not the Cartesian basis of the mirror motion.
2. What the cavity cares about is the Cartesian motion.
3. Q1: in the model, how much Cartesian pitch motion is there at the POS eigenfrequency in the free-swinging case?
4. Q2: should we somehow diag the input matrix into the Cartesian basis?
5. Q3: if so, How?
6. Q4: and why?

• Ideally, we put the chiller outside of the interferometer area. The PSL chiller used to be in the control room near the door by IMC REFL. We could also put it in the drill press room.
• Once we figure out a couple of places where the Diode Box can go, we can ask facilities to make the appropriate power connections. They will have to eval the situation to figure out if the main power to the lab needs to be shut down.
• Can we put the laser diode box in the drill press room too? Then the hoses can be short. Perhaps less EMI getting into our sensitive places.

Note from Stephen on more sensitive Baslers.

the POS column should be all 1 for the AC balancing. Where did those non-1 numbers come from?

1. I suggest not naming this the LSC model, since it has no LSC stuff.
2. Also remove all the diagnostic stuff in the plant model. We need nothing except a generic filter Module, like in the SUS controller.
3. Also, the TF looks kind of weird to me. I would like to see how you derive that eq.
4. Connect the models and show us some plots of the behavior in physical units using FOTON to make the filters and diaggui/DTT (at first) to make the plots.

The PSL was too hot, so I turned on the south HEPA on the PSL. The north one was on and the south one was off (or so slow as to be inaudible and no vibration, unlike the north one). Lets watch the trend over the weekend and see if the temperature comes down and if the PMC / WFS variations get less. Fri May 14 17:46:26 2021

Looks like the fan lowered the temperature as expected. Need to get a few more days of data to see if its stabilized, or if that's just a fluke.

The vertical line at 00:00 UTC May 18 is about when I turned the fans up/on.

Fluke. Temp fluctuations are as usual, but the overall temperature is still lower. We ought to put some temperature sensors at the X & Y ends to see what's happening there too.

What are the quantitative root causes for why the statistical uncertainty is so large? Its larger than 1/sqrt(N)

this model doesn't seem to include the analog AA, analog AI, digital AA, digital AI, or data transfer delays in the system. I think if you include those you will get more accuracy at high frequencies. Probably Anchal has those included in his DARM loop model?

I suggest plotting all the traces in the plot so we can see their differences. Also remove the 1/f^2 slope so that we can see small differences. Since the optlev servos all have low pass filters around 15-20 Hz, its not necessary to turn off the optlev servos for this measurement.

I think that based on the coherence and the number of averages, you should also be able to use Bendat and Piersol so estimate the uncertainy as a function of frequency. And we want to see the comparison coil-by-coil, not in the DoF basis.

4 sweeps for BS and 4 sweeps for PRM.

I would expect to see some lower frequency effects. i.e. we should look at the timeseries of the demod with the excitation on and off.

I would guess tat the exc on should show us the variations in the optical gain below 3 Hz, whereas the exc off would not show it.

Maybe you should do some low pass filtering on the time series you have to see the ~DC effects? Also, reconsider your AA filter design: how do you quantitatively choose the cutoff frequency and stopband depth?

I suggest that you

1. change the corner frequency to 10 Hz as I suggested last week. This filter, as it is, is going to give you trouble.
2. Put in a sine wave at 3.4283 Hz with an amplitude of 1, rather than white noise. In this way, its not necessary to do any subtraction. Just make PSD of the output of each filter.
3. Be careful about window length and window function. If you don't do this carefully, your PSD will be polluted by window bleeding.

not sure that this is necessary. If you look at teh previous entries Gautam made on this topic, it is clear that the BS/PRM PRMI matrix is snafu, whereas the ITM PRMI matrix is not.

Is it possible that the ~5% coil imbalance of the BS/PRM can explain the observed sensing matrix? If not, then there is no need to balance these coils.

For the oplev, there are DQ channels you can use so that its possible to look back in the past for long measurements. They have names like PERROR

should compare side by side with the ITM PRMI radar plots to see if there is a difference. How do your new plots compare with Gautam's plots of PRMI?

SVG doesn't work in my browser(s). Can we use PDF as our standard for all graphics other than photos (PNG/JPG) ?

rethinking what I said on Wednesday - its not a good idea to put the particle counter on a vac chamber with optics inside. The rumble from the air pump shows up in the acoustic noise of the interferometer. Let's look for a way to mount it near the BS chamber, but attached to something other than vacuum chambers and optical tables.

IFOcad model/video of the AEI 10m interferometer:

https://10m.aei.mpg.de/design-and-sensitivity/

Please don't put it on c1sus2. Put it on the completely independent test stand as we discussed Wednesday. You must test the controller on the simplant and verify that they thing is stable and works, before putting it in the 40m network.

This looks great. I think what we want to see mainly is just the noise in the 32 bit IIR filtering subtracted from the 64 bit one.

It would be good if Tega can look through your code to make sure there's NO sneaky places where python is doing some funny casting of the numbers. I didn't see anything obvious, but as Chris points out, these things can be really sneaky so you have to be next level paranoid to really be sure. Fox Mulder level paranoia.

And, we want to see a comparison between what you get and what Denis Martynov put in an appendix of his thesis when comparing the Direct Form II, with the low-noise form (also some slides from Matt Evans on thsi from a ~decade agoo). You should be able to reproduce his results. He used matlab + C, so I am curious to see if it can be done all in python, or if we really need to do it in C.

And then...we can make this a part of the IFOtest suite, so that we point it at any filter module anywhere in LIGO, and it downloads the data and gives us an estimate of the digital noise being generated.

We want to maintain the 16 kHz sample rate for the COIL DAQ channels, but nothing wrong with reducing the others.

I would suggest setting the DQ sample rates to 256 Hz for the SUS DAMP channels and 1024 Hz for the OPLEV channels (for noise diagnostics).

Maybe you can put these numbers into a new library part and we can have the best of all worlds?