40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 230 of 335 Not logged in
ID Date Author Type Category Subject
15966   Thu Mar 25 16:02:15 2021 gautamSummarySUSRepeated measurement of coil Rs & Ls for PRM/BS

Method

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).

Result

 PRM 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 BS 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

Conclusions

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:

1. Magnets on PRM are weird in some way. Note that the free-swinging measurement for the PRM showed some unexpected features.
2. The imbalance is coming from one of the drive chain - could be a busted current buffer for example.
3. The measurement technique was wrong.
15967   Thu Mar 25 17:39:28 2021 gautamUpdateComputer Scripts / ProgramsSpot position measurement scripts "modernized"

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.

Attachment 1: MCdecenter202103251735_mcmirror0.pdf
Attachment 2: MCdecenter202103251735_mcdecenter0.pdf
15968   Thu Mar 25 18:05:04 2021 gautamUpdateElectronicsStuffed HV coil drivers received from Screaming Circuits

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.

15973   Mon Mar 29 17:07:17 2021 gautamSummarySUSMC3 new Input Matrix not providing stable loop

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.

15977   Mon Mar 29 19:32:46 2021 gautamUpdateLSCREFL55 whitening checkout

I repeated the usual whitening board characterization test of:

• driving a signal (using awggui) into the two inputs of the whitening board using a spare DAC channel available in 1Y2
• demodulating the response using the LSC sensing matrix infrastructure
• Stepping the whitening gain, incrementing it in 3dB steps, and checking if the demodulated lock-in outputs increase in the expected 3dB steps.

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.

Attachment 1: REFL55wht.png
15983   Thu Apr 1 00:50:06 2021 gautamUpdateSUSPRMdiag

I spent some time investigating the PRM this evening, trying out some of the stuff we discussed in the meeting.

1. I used one of the SUS lockin oscillator to drive the butterfly mode (UL=+1, UR=-1, LL=-1, LR=+1) of the optic, @4.45 Hz, Amplitude=450cts (Oplev loops were engaged during the measurement).
2. Used the sensing matrix infrastructure to demodulate the Oplev PIT/YAW error signals, using the other lockin channel (so that oscillator is just for demodulation, it doesn't actuate on the suspension).
3. The digital demod phase was adjusted to put all of the demodulated signal in one ("I") quadrature.
4. The balancing of the coils was perturbed by adding small amounts of the naive PIT (YAW) DoF to the pringle-mode actuation, while simultaneously looking to minimize the demodulated signal in YAW (PIT).

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:

1. Added 2Hz wide BPs centered around 4.45 Hz to the "SIGNAL" FM of the BS and PRM suspension lockins.
2. Added 100mHz LPFs to the I and Q demodulated outputs.
3. Made a copy of Kiwamu's perturbcoilbalance_fourosem.py (in scripts/SUS) to add little bit of PIT/YAW to the pringle actuation.

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.

15987   Thu Apr 1 18:48:45 2021 gautamUpdateSUSMC2 Coil Balancing Test Results Success??

In these results, can you also include the new matrix and what the relative imbalances were?

15990   Fri Apr 2 01:26:41 2021 gautamUpdateElectronicsREFL55 chain checkout again, seems fine

[koji, gautam]

Summary:

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).

Details:

1. Koji prepared a spare whitening board. However, before he swapped it in, he checked the existing board and found no problems with it.
• 20mV input signal, 100 Hz was injected into the two REFL55 channels on the whitening board.
• The flat whitening gain was set to +45 dB.
• The signal levels seen in CDS was consistent with what is expected given an ADC conversion factor of 3276.8 cts/V.
2. Tried putting the REFL55 demodulated outputs into the next two channels, 5&6, (currently unused) on the same whitening board.
• After setting the whitening gains of these two channels also to +18dB, the saturation of the ADCs when the PRMI was fringing persisted.
3. With the dark noise of the whitening filter, we enabled/disabled the on board frequency dependent whitening, and reasoned that the time domain increase in RMS seemed reasonable. So we decided to investigate parts of the electronics chain upstream of the whitening board, since we couldn't find anything obviously wrong with the whitening board.
4. Injected -10dBm RF signal (=0.2 Vpp) into the RF input on the REFL55 demod board, and saw ~3500 cts-pp signal in CDS. This is totally consistent with my recent characterization of 16,000 cts/V for this demod board at the "nominal" + 18dB whitening gain setting. So the demodulator seems to function as advertised.
5. Decided to repeat my test of using the Jenne laser to test the whole chain end-to-end.
• In summary, we recovered the results (RF transimpedance of the PD, and signal levels in CDS for a known AM determined by the reference NF1611 PD) I reported there.
• So it would seem that the entire REFL55 electronics chain performs as expected.
• The only remaining explanation is that the optical gain of the PRMI has increased - but how??
• Similar jumps in the REFL55 signal levels have occurred multiple times in the past, and each time, I was able to recover the "nominal" performance by this procedure (though I have no idea why that should work at all).
• So I am highly skeptical that this has anything to do with the IFO optical gain, but that is the only difference between our AM laser based test and the "live" operating conditions when the signals are saturated.

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%.

15992   Fri Apr 2 15:17:23 2021 gautamSummaryGeneralHEPA AC cord replacement

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.

 Quote: 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.
15993   Fri Apr 2 15:22:54 2021 gautamUpdateSUSMatrix results, new measurement set to trigger

How should I try to understand why PIT and YAW are so different?

Quote:
New output matrix for MC2 (C1:SUS-MC2_TO_COIL_ii_jj_GAIN)
POS PIT YAW
UL 1 1.022 0.6554
UR 1 0.9776 -1.2532
LL 1 -0.9775 1.2532
LR 1 -1.0219 -0.6554
15994   Sat Apr 3 00:42:40 2021 gautamUpdateLSCPRFPMI locking with half input power

Summary:

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

Details:

1. The waveplate I installed for this purpose was rotated until the MC RFPD DCMON channel reported ~half it's nominal value.
2. I adjusted the IMC servo gains appropriately to compensate. IMC lock was readily realized.
3. I increased the whitening gains on the POX, POY and REFL165 photodiodes by 6dB, to compensate for the reduced light levels.
• One day soon, we will have remote power control, and it'd be nice to have this process be automated.
• Really, we should have de-whitening filters that undo these flat gains in addition to undoing the frequency dependent whitening.
• I'm not sure the quality of the electronics is good enough though, for the changing electronics offsets to not be a problem.
• One possibility is that we can normalize some signals by the DC light level at that port, but I still think compensating the changing optical gain as far upstream as possible is best, and the whitening gain is the convenient stage to do this.
4. Recovered single arm POX/POY locking.
5. Then I decided to try and lock the PRFPMI with the reduced input power.

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.

Discussion:

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.

Attachment 1: PRFPMIlock_1301464998_1301465238.pdf
Attachment 2: CARMplant.pdf
15996   Mon Apr 5 22:26:01 2021 gautamUpdateLSCPRMI 1f locking (no ETMs) recovered

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:

1. I made some changes to the presentation so that the units of the sensing matrix are now in [W/m] sensed on a photodiode.
• The info printed on the plot is also more verbose, I now indicate explicitly the actuator driven to make the measurement, and also the drive frequency. The various gains used to convert counts to Watts on a photodiode are also indicated.
• I thought about printing the actual matrix too but haven't arrived at a clean prez style yet.
• This is to facilitate easier comparison to Finesse models / analytic calcs.
• I take into account all the gains from the photodetector to the servo error point where the measurement is made. However, the splitting fractions between various photodiodes is not included, so you will have to do that yourself when comparing to a Finesse model.
• For example, in pg2 of Attachment #1, the measured gain of PRCL sensed in REFL55_I is ~2e6 W/m. But only ~4% of IFO REFL ends up on the REFL55 photodiode. So, this measurement would be consistent with a Finesse simulated optical gain of ~50MW/m, which is in the ballpark of what I do actually see.
2. There seems to be reasonable agreement between Finesse and these measurements. But why should the old settings / locking have worked at all then?
3. I tried two schemes for MICH actuation today.
• The first was the usual BS + PRM combo, and I got the sensing matrix on pg 1 of Attachment #1. With this scheme, the MICH/PRCL orthogonality is a joke.
• Then I changed the MICH actuator to the ITMs, and got the sensing matrix on pg 2 of Attachment #1. With this scheme, the orthogonality looks much better. I think the slight non-orthogonality in the 11/33 MHz photodiodes may even be reasonable, since the 11 MHz field isn't a good sensor of the anti-symmetric modes, but have to confirm by calculation/simulation. But certainly the separation of signals is much cleaner when the ITMs are used to control MICH.

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.

Attachment 1: PRMI_Apr5sensMat_consolidated.pdf
16006   Wed Apr 7 22:48:48 2021 gautamUpdateIOOWaveplate commissioning

Summary:

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.

Part numbers:

• The controller is a NewFocus ESP300.
• The waveplate stage is a PR50CC. The waveplate itself that is mounted has a 1" diameter (clear aperture is more like 21mm), which I think is ~twice the size of the waveplates we have in the lab, good thing Livingston shipped us the waveplate itself too. It is labelled QWPO-1064-10-2, so should be a half wave plate as we want, but I didn't explicitly check with a linearly polarized beam today. Before any serious high power tests, we can first contact clean the waveplate to avoid any burning of dirt. The damage threshold is rated as 1 MW/cm^2, and I estimate that we will be well below this threshold for any power levels (<30W) we are planning to put through this waveplate. For a 100um radius beam with 30W, the peak intensity is ~0.2 MW/cm^2. This is 20% of the rated damage threshold, so may be better to enforce that the beam be >200um going through this waveplate.
• The dimensions of the mount look compatible with the space we have on the PSL table (though of course once the amplifier comes into the picture, we will have to change the layout. Maybe it's better to keep everything downstream of the PMC fixed - then we just re-position the seed beam (i.e. NPRO) and amplifier, and then mode-match the output of the amplifier to the PMC.

Electrical tests:

1. First, I connected a power cord to the ESP300 and powered it on - the front display lit up and displayed a bunch of diagnostics, and said something to the effect of "No stage connected".
2. Next, I connected the rotary mount to "Axis #1": Male DB25 on the stage to female DB25 on the rear of the ESP300. The stage was recognized.
3. Used the buttons on the front panel to rotate the waveplate, and confirmed visually that rotation was happening 👍 . I didn't calibrate the actual degrees of rotation against the readback on the front panel, but 45 degrees on the panel looked like 45 degrees rotation of the physical stage so seems fine.

RS232 tests:

• This unit only has a 9-pin Dsub connector to interface remotely to it, via RS232 protocol. c1psl Supermicro host was designated the computer with which I would attempt remote control.
• To test, I decided to use a serial-USB adapter. Since this is only a single unit, no need to get an RS232-ethernet interface like the one used in the vacuum rack, but if there are strong opinions otherwise we can adopt some other wiring/control philosophy.
• No drivers needed to be installed, the host recognized the adapter immediately. I then shifted the waveplate and controller assembly to inside the VEA - they are sitting on a cart behind 1X2. Once the controller was connected to the USB-serial adapter cable, it was registered at /dev/ttyUSB0 immediately. I had to chown this port to the controls user for accessing it using python serial
• Initially, I was pleasantly surprised when I found not one but TWO projects on PyPi that already claimed to do what I want! Sadly, neither NewportESP1.1 nor PyMeasure0.9.0 actually worked - the former is for python2 (and the string typesetting has changed for PySerial compatible with python3), while the latter seems to be optimized for Labview interfacing and didn't play so nice with the serial-USB adapter. I didn't want to spend >10mins on this and I know enough python serial to do the interfacing myself, so I pushed ahead. Good thing we have several pySerial experts in the group now, if any of you want to figure out how we can make either of these two utilities actually work for us - there is also this repo which claims to work for python 3 but I didn't try it because it isn't a managed package.
• The command list is rather intimidating, it runs for some 100 (!) pages. Nevertheless, I used some basic commands to readback the serial number of the controller, and also succeeded in moving the stage around  by issuing the "PR" command appropriately 👍. BTW, I forgot that I didn't test the motor enable/disable which is an essential channel I think.
• I think we actually only need a very minimal set of commands, so we don't need to read all 100 pages of instructions:
• motor enable/disable
• absolute and relative rotations
• readback of the current position
• readback of the moving status
• a stop command
• an interlock
• Note that as a part of this work, in addition to chowning /dev/ttyUSB0, I installed the two aforementioned python packages on c1psl. I saw no reason to manually restart the modbus and latch services running on it, and I don't believe this work would have impacted the correct functioning of either of those two services, but be aware that I was poking around on c1psl. I was also reminded that the system python on this machine is 2.7 - basically, only the latch service that takes care of the gains for the IMC servo board are dependent on python (and my proposed waveplate control script will be too), but we should really upgrade the default python to 3.7/3.8.

Next steps:

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

• We need to use a long-ish cable to run from 1X1/1X2, where the controller will be housed, to the PSL enclosure. Livingston did ship one such long cable (still on Rana's table), but I didn't check if the length is sufficient / the functionality of this long cable.
• We need to set up some EPICS channels for the rotation stage angle, motor ENABLE/DISABLE, a "move stage" button, motion status, and maybe a channel to control the rotation speed?
• We need a python script that is reading from / writing to these EPICS channel in a while loop. Should be straightforward to setup something to run like the latch.py service that has worked decently reliably for ~a year now. afaik, there isn't a good way to run this synchronously, and the delay in sending/completing the execution of some of the serial commands might be ~1 second, but for the purpose of slowly ramping up the power, this shouldn't be a problem.
• One question I do have is, what is the strategy to protect the IFO from the high power when the lock is lost? Surely we are not gonna rely on this waveplate for any fast actuation? With the current input power of 1W, the MCREFL photodiode sees ~100mW when the IMC loses lock. So if the final input power is 35W, do we wanna change the T=10% beamsplitter in the MCREFL path to keep this ratio?

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.

Attachment 1: remotePowCtrl.pdf
16022   Tue Apr 13 17:47:07 2021 gautamUpdateIOOWaveplate commissioning - software prepared

I spent some time today setting up a workable user interface to control the waveplate.

1. Created some EPICS database records at /cvs/cds/caltech/target/ESP300.db. These are all soft channels. This required a couple of restarts of the modbus service on c1psl - as far as I can tell, everything has come back up without problems.
2. Hacked newportESP to make it work, mainly some string encoding BS in the python2-->python3 paradigm shift.
3. Made a python script at /cvs/cds/caltech/target/ESP300.py that is based on similar services I've set up for the CM servo and IMC servo boards. I have not yet set this up to run as a service on c1psl, but that is pretty trivial.
4. Made a minimal MEDM screen, see Attachment #1. It is saved at  /opt/rtcds/caltech/c1/medm/c1psl/C1PSL_POW_CTRL.adl and can be accessed from the "PSL" tab on sitemap. We can eventually "calibrate" the angular position to power units.
5. Confirmed that I can move the waveplate using this MEDM screen.

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.

Attachment 1: remoteHWP.png
16023   Tue Apr 13 19:24:45 2021 gautamUpdatePSLHigh power operations

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

• T_PMC ~85% which is what I measured it to be back in 2019
• T_IMC * T_inputFaraday ~60% which is what I estimate it to be now
• 98% mode matching into the IMC
• power recycling gain of 40-45 once we improve the folding mirror situation in the recycling cavities
• and a gain of 270-280 in the arm cavities (20-30ppm round trip loss)

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.

Attachment 1: intensityDist.pdf
Attachment 2: clippingLoss.pdf
16025   Wed Apr 14 12:27:10 2021 gautamUpdateGeneralLab left open again

Once again, I found the door to the outside in the control room open when I came in ~1215pm. I closed it.

16028   Wed Apr 14 14:52:42 2021 gautamUpdateGeneralIFO State

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).

Attachment 1: IFOSTATE.png
16032   Wed Apr 14 19:48:18 2021 gautamUpdatePSLLaser amplifier

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.

16033   Wed Apr 14 23:55:34 2021 gautamUpdateElectronicsHV Coil driver assembly

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.

16036   Thu Apr 15 15:54:46 2021 gautamUpdateIOOWaveplate commissioning - hardware installed

[jordan, gautam]

We did the following this afternoon.

1. Disconnected the cable from the unused (and possibly not working) RefCav heater power supply, and removed said PS from 1X1. There was insufficient space to install the ESP300 controller elsewhere. I have stored the power supply along the east arm under the beamtube, approximately directly opposite the RFPD cabinet.
2. Installed the ESP 300 - conveniently, the HP DCPS was already sitting on some rails and so we didn't need to add any.
3. Ran a long D25-D25 cable from the ESP300 to the NE corner area of the PSL enclosure. The ends of the cable are labelled as "ESP end" and "Waveplate end". The HEPA was turned on for the duration we had the enclosure open, and I have now turned it off.
4. Connected the waveplate to this cable. Also re-connected the ESP300 to the c1psl supermicro host via the USB-RS232 adapter cable.

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.

 Quote: 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.

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?

16073   Thu Apr 22 14:22:39 2021 gautamUpdateSUSSettings restored

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.

Attachment 1: MCdamping.png
16075   Thu Apr 22 14:49:08 2021 gautamUpdateComputer Scripts / Programsrossa added to RTS authorized keys

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.

16076   Thu Apr 22 15:15:26 2021 gautamUpdatePSLPMC transmission

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?

 Quote: The transmitted power was ~50-60 mW. (Had to use power meter suspended by hand only.
16079   Thu Apr 22 17:04:17 2021 gautamUpdateSUSSettings restored

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...

 Quote: 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?
16082   Fri Apr 23 18:00:02 2021 gautamUpdatePSLHEPA speed lowered

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.

16097   Thu Apr 29 15:11:33 2021 gautamUpdateCDSRFM

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.

Attachment 1: RFM_errs.png
Attachment 2: Screenshot_2021-04-29_15-12-56.png
16104   Fri Apr 30 00:18:40 2021 gautamSummaryLSCStart of measuring IMC WFS noise contribution in arm cavity length noise

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.

 Quote: I calibrated the control arms signals by 2.44 nm/cts calibration factor directly picked up from 13984.
16105   Fri Apr 30 00:20:30 2021 gautamUpdateCDSF2A Filters double check

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.

 Quote: 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
16142   Sat May 15 12:39:54 2021 gautamUpdatePSLNPRO tripped/switched off

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.

Attachment 1: NPRO.png
16143   Sat May 15 14:54:24 2021 gautamUpdateSUSIMC settings reverted

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.

 Quote: 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.

Attachment 1: MC2coilOut.png
16162   Wed May 26 02:00:44 2021 gautamUpdateElectronicsCoil driver noise

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 $\sqrt{2eI_{\mathrm{DC}}} \approx$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 $\sqrt{2eI_{\mathrm{DC}}/3} \approx$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 $I=V/R$ and that's what sets the current noise. See, for example, pg 432 of Horowitz and Hill.

Attachment 1: coilDriverTopologies.pdf
Attachment 2: shotVthermal.pdf
16245   Wed Jul 14 16:19:44 2021 gautamUpdateGeneralBrrr

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?

 Quote: - 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.
Attachment 1: rmTemp.pdf
16247   Wed Jul 14 20:42:04 2021 gautamUpdateLSCLocking

[paco, gautam]

we decided to give the PRFPMI lock a go early-ish. Summary of findings today eve:

1. Arms under ALS control display normal noise and loop UGFs.
2. PRMI took longer than usual to lock (when arms are held off resonance) - could be elevated sesimic, but warrants measuring PRMI loop TFs to rule out any funkiness. MICH loop also displayed some saturation on acquisition, but after the boosts and other filters were turned on, the lock seemed robust and the in-loop noise was at the usual levels.
3. We are gonna do the high bandwidth single arm locking experiments during daytime to rule out any issues with the CM board.

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.

16249   Fri Jul 16 16:26:50 2021 gautamUpdateComputersDocker installed on nodus

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).

12384   Tue Aug 9 00:44:43 2016 gautam UpdateSUSETMY patch-up

Summary:

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

• I used the teflon+glass rig Steve put together for this purpose
• After soaking for ~2 hours in acetone, I was able to remove approximately half of the ring residue by lightly pushing with a wipe.
• The other half wouldn't budge so I let it soak for another 4 hours
• After 6 hours of soaking, I was able to get all of the epoxy residue off - it doesn't simply dissolve in the acetone, I had to push a little with one of the cotton-tipped paddles in the cleanroom
• I gave the portion exposed to acetone a quick drag wipe with isopropanol. I didn't spend too much time trying to clean the AR side given that we will be using first contact anyways.
• I have not touched the HR side for now, even though a small portion of it was exposed to acetone. While cleaning the HR face with first contact, this portion can be inspected and cleaned if necessary

Step 2: Putting the optic in the magnet gluing jig

• I transferred the optic to the magnet gluing jig
• Given that we weren't touching any side magnets, I reasoned I did not have to go through the elaborate shimming routine to account for the wedge of the optic that we had to do in the recent past
• However, I did not think to put a thicker teflon spacer on the lower side of the wedge, and as a result, I knocked off the UR magnet as well as the jig did not have sufficient clearance
• Fortunately, the UR magnet came off cleanly, there was hardly any epoxy residue left on the optic. The UR magnet was NOT one of the magnets knocked off by Johannes while removing the optic from the vacuum chamber
• I gave the area formerly occupied by the UL magnet 3-4 wipes with acetone and then 1-2 wipes with isopropanol
• At this stage, I proceeded to re-insert the magnet-gluing jig. I used the two scribe lines on the outer side of the jig to fix the rotation of the jig, and used the remaining two attached face magnets to fix the overall position of the jig (by centering these magnets relative to the apertures on the jig). In order to center well, I had to unscrew the stuck silver plated screw on the jig by 1 turn
• Having arranged the jig satisfactorily, I proceeded to remove epoxy residue off the dumbbell of the recently knocked off UL magnet using first a razor blade, then sandpaper and finally made some new grooves with a razor blade. I then cleaned the surface of the dumbbell to be in contact with the optic with isopropanol. All of this was done for the LR magnet two weeks ago right after it was knocked off

Step 3: Gluing the magnets

• I prepared the magnets in the pickle pickers
• I discarded 1 full squeeze of the epoxy after it reached the tip of the mixing fixture, and then extracted another full squeeze of the gun for mixing and gluing the magnets
• I mixed the epoxy in an Al foil vessel for 3-4 minutes, and then placed a few drops on a piece of Al foil for a test bake at 200F for ~15 minutes
• The test bake went well, so I proceeded to apply glue to the dumbbells and re-glue the magnets to the optic
• The gluing was done around midnight, so we should be able to have a look at this post lunch tomorrow.

Provided the gluing goes well, the plan for tomorrow is:

1. Bring ETMY suspension tower from the vacuum chamber to the cleanroom along with its OSEMs
2. Suspend ETMY with a new length of wire (this should be much more straightforward than our ETMX exploits as both standoffs are already glued)
3. Insert OSEMs, check that all 4 face magnets are well centered w.r.t. their coils and also that at least one side magnet is well aligned relative to its coil and can be used
4. If step 3 goes well, then ETMY is also ready for a vacuum bake. I guess we can also air bake the ETMY suspension tower, there's plenty of room in the oven
12386   Tue Aug 9 15:27:57 2016 gautam UpdateSUSETMY patch-up

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:

• The ETMY suspension seems to be of an older generation - it does not have the the two secondary wire clamps.
• The top piece was attached to the body of the tower using non-silver-plated screws. Steve tells me this is the wrong type, and we can switch these out when we put it back together.
• The wire clamp itself doesn't have much of a groove from the wire. But the wires have made asymmetric grooves in the tower itself (the left groove is deeper than the right as seen in Attachment #1), that are clearly visible. Should we get these grooves removed before attempting re-suspension? How do we want to remove it? Steve thinks the best option is to send it to the shop for milling, as there is hardly any room to rub sandpaper along the piece because of the pins, and these pins don't come out.
• Or do we just not care about these grooves for now, if we are planning to use new wire anyways after air-baking the towers?
• Steve thinks we should have a few spares of these top blocks handy (the latest version, with the secondary clamps), he wants to know if we should place an order for these (we already have 10 spare wire clamp pieces available for if/when we need them)

Attachment #2 - the base of the tower is significantly rusty:

• A few wipes with an acetone soaked rag yielded quite a lot of rust
• Steve thinks this is because the wrong type of stainless steel was used
• Does this have to do with the cage being of an older variety? After a few vigorous wipes, no more rust came off, but the rusting process will presumably keep generating new rust? Is this a concern? Do we want to change this piece before putting the tower back in?

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.

Attachment 1: IMG_2996.JPG
Attachment 2: IMG_2997.JPG
12390   Wed Aug 10 03:08:03 2016 gautam UpdateSUSETMY patch-up

[lydia, gautam]

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:

• Transferred optic from magnet gluing rig to the suspension cage
• Adjusted bottom EQ stops till the scribe lines on both sides were at 5.5" as verified with the microscope
• Looped cleaned length of wire around optic, attached free ends to winches, placed the wires under light tension by finger-pulling the slack out
• Lowered the bottom EQ stops
• Winched the optic to the right height
• Clamped the wire with the only wire clamp on this variant of the suspension cage. We used the same torque wrench at the same torque setting as was successful for ETMX. But after removing the winches, and releasing the face EQ stops, the optic seems to have sagged a lot - it now touches all the bottom EQ stops, and the more I lower it, the more it seems to come down. Perhaps it is the effect of the wire grooves in the cage, or that the wire-clamp itself is slightly different from the piece used on the ETMX cage, but 1.3Nm of torque doesn't seem to have tightened the wire clamp sufficiently
• We can still probably salvage the situation by re-attaching the winches to the top of the cage, setting the optic to the right height again, and clamping the wire clamp with more torque (as this is just a check to see that the reglued magnet configuration is compatible with the OSEM coil positions on the cage). Before air baking the cage, we will have the old wire grooves removed, and then suspend the optic with a fresh loop of wire after the bake
• We could not check the magnet-OSEM alignment because of the slipping of the wire through the clamp. We decided against pushing on tonight
• Optic is currently in the cage, resting on the bottom EQ stops and with all face EQ stops within 1mm of the optic. The OSEM coils have not been inserted into the holders

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?

12397   Wed Aug 10 23:45:03 2016 gautam UpdateSUSETMY re-suspended

Summary:

• ETMY has been re-suspended
• Reglued magnets (and also those that weren't knocked off) quite well with OSEM coils (see attachments)
• Pitch balance is off by ~2.8mrad (8mm over 1.5m lever arm) after inserting and centering OSEMs
• The same damping scheme used during the ETMX re-suspension process works reasonably well with ETMY as well

Details:

• I suspected that I had not tightened the wire clamp enough yesterday, and that the wire had slipped once the winches were removed
• Steve and I looked into the torque wrench situation today, and I realised that I had not been using the torque wrench correctly. What I thought were clicks indicating that the set torque has been reached was in fact just the sound the piece makes when going the opposite way relative to the direction set by the clip on the torque wrench. Anyways, the point is that while I thought I was tightening the screws with ~1.3Nm of torque, what was actually being applied was much less (although I don't have a good way to quantify how much less)
• So today I put the winches back on top of the tower, and winched the optic back up to the correct height using the ususal scribe line + microscope prescription
• I then tightened the wire clamp by hand. This is obviously not very repeatable, but it will have to do until we get a torque wrench with the correct range
• This seems to have done the trick - I did the tightening shortly after lunch, and after ~10 hours, there is no evidence of any wire sag
• I then proceeded to insert the OSEMs, first not all the way in to check the clearance available to the magnet, and once I was satisfied there was no danger of knocking anything off, went ahead and inserted the coils till the PD readouts were approximately half of the maximum (i.e. fully un-occluded) values. I used the OSEM coils originally on the ETMY tower, but all the other readout and drive electronics in the signal chain (satellite box included) belong to the ETMX setup (so as to avoid any cable routing over 80m from the Y end to the cleanroom). After some adjustment of the OSEM holding plates, I was able to center the magnets relative to the coils
• The tower only allows for a side OSEM to be inserted on one side. The other side does not have a threaded hole for a set screw. So we are forced to use the reglued magnet and not the side magnet that was not knocked off. By eye, it looks like the magnet may never completely occlude the LED, but the Striptool trace I was using to monitor the output of the PD did not yield any conclusive evidence. The optic was moving around a lot and I did not perform this check after turning the damping on
• I was able to damp the optic as well as we were able to damp ETMX on the clean bench (with the HEPA turned OFF). I had to turn the YAW gain down from 100-->75 to avoid some oscillations
• I then proceeded to check the pitch balance with the HeNe. The spot is low on an iris 1.43m away by ~8mm, which corresponds to a pitch misalignment of ~2.8mrad. I am not sure what to make of this - but perhaps its not unreasonable that we see this? Is there any record of what fine pitch balancing was achieved when the optic was put together back in 2010? This is also very sensitive to how far in/out the OSEM coils are, and though I've tried to center the coils as best as I can, I obviously have not done a perfect job...

What's next?

• Is the observed pitch imbalance a deal breaker? If so, I guess we need to re-glue a standoff?
• Are we willing to accept the side OSEM situation? (Tomorrow, I need to do a check to see what, if any, dynamic range we lose, with the damping on)
• If both the above are not problems we need to worry about, then:
• ETMY + ETMX -------> Vacuum bake on 22nd August (? - Bob also told me earlier today that he will try and put in some old turbo pump next week, and if that works, we could possibly get in the queue even before the 22nd)
• ETMY tower -------> Steve for sanding and removing wire grooves -------> Air bake
• ETMX tower -------> Air bake (provided the latest round of wire tightening has not left any grooves in the top piece of the tower, if it has, this needs to be cleaned up too)
• Some lengths of SOS wire (for re-suspending optics after bake) -------> Air bake

Attachments:

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

Attachment 1: ETMY_OSEMStrip.PDF
Attachment 2: IMG_2998.JPG
Attachment 3: IMG_3000.JPG
Attachment 4: IMG_3001.JPG
Attachment 5: IMG_3002.JPG
Attachment 6: IMG_3003.JPG
Attachment 7: IMG_3004.JPG
12758   Wed Jan 25 19:39:07 2017 gautam UpdateIMC29.5 MHz modulation depth measurement plan

Just collecting some links from my elog searching today here for easy reference later.

• EOM datasheet: Newfocus 4064 (according to this, the input Impedance is 10pF, and can handle up to 10W max input RF power).
• An elog thread with some past measurement details: elog 5339. According to this, the modulation depth at 29.5 MHz is 4mrad. The EOM's manual says 13mrad/V @1000nm, so we expect an input signal at 29.5MHz of 0.3V(pk?). But presumably there is some dependance of this coefficient on the actual modulation frequency, which I could not find in the manual. Also, Kiwamu's note (see next bullet) says that the EOM was measured to have a modulation depth of 8 mrad/V
• A 2015 update from Kiwamu on the triple resonant circuit: elog 11109. In this elog, there is also a link to quite a detailed note that Kiwamu wrote, based on his analysis of how to make this circuit better. I will go through this, perhaps we want to pursue installing a better triple resonant circuit...

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.

14750   Thu Jul 11 13:09:22 2019 gautam SummaryCDSP2 interface board

it will connect to a 15 pin breakout board in the Acromag chassis

 Quote: 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?
11599   Tue Sep 15 15:10:48 2015 gautam, ericq, ranaSummaryLSCPRFPMI lock & various to-do's
I was observing Eric while he was attempting to lock the PRFPMI last night. The handoff from ALS to LSC was not very smooth, and Rana suggested looking at some control signals while parked close to the PRFPMI resonance to get an idea of what frequency bands the noise dominated in. The attached power spectrum was taken while CARM and DARM were under ALS control, and the PRMI was locked using REFL_165. The arm power was fluctuating between 15 and 50. Most of the power seems to be in the 1-5Hz band and the 10-30Hz band.

Rana made a number of suggestions, which I'm listing here. Some of these may directly help the above situation, while the others are with regards to the general state of affairs.

• Reroute both (MC and arm) FF signals to the SUS model
• For MC, bypass LSC
• Rethink the MC FF -
• Leave the arm FF on all the time?
• The positioning of the accelerometer used for MC FF has to be bettered - it should be directly below the tank
• The IOO model is over-clocking - needs to be re-examined
• Fix up the DC F2P - Rana mentioned an old (~10 yr) script called F2P ratio, we should look to integrate the Python scripts used for lock-in/demod at the sites with this
• Look to calibrate MC_F
• Implement a high BW CARM servo using ALS
• Gray code implementation for EPICS gain-stepping

Attachment 1: powerSpec0915.pdf
11579   Fri Sep 4 20:42:14 2015 gautam, ranaUpdateCDSCheckout of the Wenzel dividers

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:

1. They run on +15V power.
2. For low RF frequencies (< 40 MHz) the signal level can be as low as -25 dBm.
3. For frequencies up to 130 MHz, the signal should be > 0 dBm.
4. In all cases, we get a square wave going from 0 ~ 2.5 V, so the limiter inside keeps the output amplitude roughly fixed at a high level.
5. When the RF amplitude goes below the minimum, the output gets shaky and eventually drops to 0 V.

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.

Attachment 1: TEK00000.PNG
Attachment 2: TEK00001.PNG
Attachment 3: TEK00002.PNG
11940   Wed Jan 20 23:26:10 2016 gautam, ranaUpdateLSCPSL and AUX-X temperatures changed

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...

Details:

• PSL shutter was closed and FSS servo input was turned off.
• As I had mentioned in this elog, the beat can now only be found at 47.41 degress +/- 1 deg, which is a shift of almost 5 degrees from the value set sometime last year, ~42.6 degrees. Rana thought it's not a good idea to keep operating the laser at such a high crystal temperature, so we decided to lower the X-end laser temperature back to 42.6 degrees, and then adjust the PSL temperature appropriately such that we found a beat. The diode temperature was also tweaked (this requires using a small screwdriver to twist the little knob inset to the front panel of the laser controller) - for the end laser, we did not have a dedicated power monitor to optimize the diode temperature by maximizing the current, and so we were just doing this by looking at the beat note amplitude on the network analyzer (which wasn't changing by much). So after playing around a little, Rana decided to leave it at 31.3 degrees.
• We then went to the PSL table and swept through the temperature till a beat was found. The PMC wouldn't stay locked throughout the sweep, so we first did a coarse scan, and saw weak (due to the PMC being locked to some weird mode) beatnotes at some temperatures. We then went back to 29.41 degrees, and ran the PMC autolocker script to lock the PMC - a nice large beatnote was found.
• Finally, Rana tweaked the temperatures of the two diodes on the PSL laser controller - here, the optimization was done more systematically, by looking at the PMC transmitted power on the oscilloscope (and also the MEDM screen) as a function of the diode temperature.
• I took a quick look at the ALS out of loop noise - and unfortunately, our efforts today does not seem to have noticeably improved anything (although the bump at ~1kHz is no longer there).

Some details not directly related to this work:​

• There are long cables (routed via cable tray) suitable for RF signals that are running from the vertex to either end-table - these are labelled. We slightly re-routed the one running to the X-end, sending it to the IOO rack via the overhead cable tray so that we could send the beat signal from the frequency counter module to the X-end, where we could look at it using an analyzer while also twiddling laser parameters.
• A webcam (that also claims to have two-way audio!) has been (re?)installed on the PSL table. The ethernet connection to the webcam currently goes to the network switch on the IOO rack (though it is unlabelled at the moment)
• The X-end area is due for a clean-up, I will try and do some of this tomorrow.
Attachment 1: 2016_01_20_ALS_OutOfLoop_1.pdf
2246   Thu Nov 12 01:18:34 2009 haixingUpdateSUSopen-loop transfer function of mag levi system (comparison between simulink and measurement)

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.

2274   Mon Nov 16 15:18:10 2009 haixingUpdateSUSStable magnetic levitation without eddy-current damping

By including a 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:

4086   Wed Dec 22 11:24:23 2010 haixingUpdateSUSmeasurement of imbalance in quadrant maglev protope

Yesterday, a sequence of force and gain measurement was made to determine the imbalance in the

quadrant, magnetic-levitation prototype. This was the reason why it failed to achieve a stable levitation.

The configuration is shown schematically by the figure below:

Specifically, the following measurements have been made:

(1) DC force measurement among four pairs of magnets at fixed distance with current of the coils on and off

From this measurement,  the DC force between pair of magnets is determined and is around 1.6 N at with a

separation of 1 cm. This measurement also lets us know the gain from voltage to force near the working point.

The force between pair "2" is about 13% stronger than other pairs which are nearly identical. The force by the

coil is around 0.017 N per Volt (levitation of 5 g per 3 Volt); therefore, we need around 12 volt DC compensation

of pair "2" in order to counterbalance such an imbalance.  Given the resistence of the coil equal to 26 Om, this

requires almost 500 mA DC compensation. Koji suggested that we need a high-current buffer, instead of what

has been used now.

(2) DC force measurement among four pairs of magnets (with current of the coils off) as a function of distance

From this measurement, we can determine the stiffness of the system. In this case, the stiffness or the

effective spring constant is negative, and we need to compensate it by using a feedback control. This is

one of the most important parameters for designing the feedback control. The data is still in processing.

(3) Gain measurement of the OSEM from the displacement to voltage.

This measurement is a little bit tricky due to the difficulty to determine the displacement of the flag.

After several measurements, it gave approximately 2 V/cm.

Plan for the next few days:

From the those measurements, all the parameters for the plant and sensor that need to determine the

feedback control are known. They should be plugged into the simulink model and to see whether the

old design is appropriate or not. Concerning the experimental part, we will first try to levitate the configuration

with 2 pairs of magnets, instead of 4 pairs, as the first step, which is easier to control but still interesting.

4906   Wed Jun 29 01:23:21 2011 haixingUpdateSUSissues in the current quad maglev system

Here I show several issues that we have encountered in the quad magnetic levitation system. It would be great if you can give
some suggestions and comments (Poor haixing is crying for help)

The current setup is shown by the figure below (I took the photo this morning):

Basically, we have one heavy load which is rigidly connected to a plane that we try to levitate. On corners of the
plane, there are four push-fit permanent magnets. Those magnets are attracted by four other magnets which are
mounted on the four control coils (the DC force is to counteract the DC gravity). By sensing the position of the plane
with four OSEMs (there are four flags attached on the plane), we try to apply feedback control and levitate the plane.
We have made an analog circuit to realize the feedback, but it is not successful. There are the following main issues
that need to be solved:

(1) DC magnetic force is imbalanced, and we found that one pair has a stronger DC force than others. This should
be able to solved simply by replacing them with magnets have comparable strength to others.

(2) The OSEM not only senses the vertical motion, but also the translational motion. One possible fast solution is to
cover the photodiode and only leave a very thin vertical slit so that a small translational motion is not sensed.
Maybe this is too crappy. If you have better ideas, please let me know. Koji suggested to use reflective sensing
instead of OSEM, which can also solve the issue that flags sometimes touche the hole edge of the OSEM and
screw up the sensing.

(3) Cross coupling among different degrees of freedom. Basically, even if the OSEM only senses the vertical motion,
the motion of four flags, which are rigidly connected to the plane, are not independent. In the ideal case, we only
need to control pith, yaw and vertical motion, which only has three degrees of freedom, while we have four sensing outputs
from four OSEMs. This means that we need to work out the right control matrix. Right now, we are in some kind of dilemma.
In order to obtain the control matrix, we first have to get the sensing matrix or calibrate the cross coupling; however, this is
impossible if the system is unstable. This is very different from the case of quad suspension control used in LIGO,
in which the test mass is stable suspended and it is relatively easy to measure the cross coupling by driving the test mass
with coils. Rana suggested to include a mechanical spring between the fixed plane and levitated plane, so that
we can have a stable system to start with. I tried this method today, but I did not figure out a nice way to place the spring,
as we got a hole right in the middle of the fixed plane to let the coil connectors go though. As a first trial, I plan to
replace the stop rubber band (to prevent the plane from getting stuck onto the magnets) shown in the figure with mechanical
springs. In this case, the levitated plane is held by four springs instead of one. This is not as good as one, because
of imbalance among the four, but we can use this setup, at least, to calibrate the cross coupling. Let me know if you come
up better solution.

After those issues are solved, we can then implement Jamie's Cymac digital control, which is now under construction,
to achieve levitation.

4992   Tue Jul 19 21:05:55 2011 haixingUpdateDAQchoose the right relay

Rana and I are working on the AA/AI circuit for Cymac. We need relays to bypass certain paths in the circuit, and we just found a nice website
explaining how to choose the right relay:

http:/zone.ni.com/devzone/cda/tut/p/id/2774

This piece of information could be useful for others.

5019   Fri Jul 22 15:39:55 2011 haixingUpdateSUSmatching the magnets

Yi Xie and Haixing,

We used the Gauss meter to measure the strength distribution of bought magnets, which follows a nice Gaussian distribution.
We pick out four pairs--four fixed magnets and four for the levitated plate that are matched in strength. The force difference is
anticipated to be within 0.2%, and we are going to measure the force as a function of distance to further confirm this.

In the coming week, we will measure various transfer functions in the path from the sensors to the coils (the actuator). The obtained
parameters will be put into our model to determine the control scheme. The model is currently written in mathematica which can
analyze the stability from open-loop transfer function.

ELOG V3.1.3-