40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 5 of 168  Not logged in ELOG logo
Entry  Mon May 24 08:38:26 2021, Chub, Update, Electronics, 18-bit AI, 16-bit AI and 16-bit AA 

- High priority units: 2x 18AI / 1x 16AI / 3x 16AA

All six are reworked and on the electronics workbench. The rest should be ready by the end of the week.

Chub

Entry  Fri May 21 12:12:11 2021, Paco, Update, NoiseBudget, AUX PDH loop identification 

[Anchal, Paco]

We went into 40m to identify where XARM PDH loop control elements are. We didn't touch anything, but this is to note we went in there twice at 10 AM and 11:10 AM.

Entry  Fri May 21 00:15:33 2021, Koji, Update, Electronics, DC Power Strip delivered / stored 9x

DC Power Strip Assemblies delivered and stored behind the Y arm tube (Attachment 1)

  • 7x 18V Power Strip (Attachment 2)
  • 7x 24V Power Strip (Attachment 2)
  • 7x 18V/24V Sequencer / 14x Mounting Panel (Attachment 3)
  • DC Power Cables 3ft, 6ft, 10ft (Attachments 4/5)
  • DC Power Cables AWG12 Orange / Yellow (Attachments 6/7)

I also moved the spare 1U Chassis to the same place.

  • 5+7+9 = 21x 1U Chassis (Attachments 8/9)

 

Entry  Thu Aug 20 00:21:51 2020, gautam, Update, Electronics, First look at HV coil driver IMG_8724.JPGtimeDomain.pdfHVampNoise.pdf

Summary:

A single channel of this board was stuffed (and other channels partially populated). The basic tests passed, and nothing exploded! Even though this is a laughably simple circuit, it's nice that it works.

HV power supplies:

A pair of unused KEPCO BHK300-130 switching power supplies that I found in the lab were used for this test. I pulled the programmable cards out at the rear, and shorted the positive output of one unit to the negative of the other (with both shorted to the supply grounds as well), thereby creating a bipolar supply from these unipolar models. For the purposes of this test, I set the voltage and current limits to 100V DC, 10mA respectively. I didn't ramp up the supply voltage to the rated 300 V maximum. The setup is shown in Attachment #1.

Tests:

  1. With the input to the channel shorted to ground, I confirmed with a DMM that the output was (nearly) zero (there was an offset of ~40mV but I think this is okay).
  2. Used the calibrated voltage source, and applied +/- 3 V in steps of ~0.5 V, while monitoring the output with a DMM. Confirmed the output swing of ~ +/-90 V, which is what is expected, since the design voltage gain of this circuit is 31.
  3. Drove a 0.1 Hz, 500mVpp sine wave at the input while monitoring the output and the Vmon testpoints, see Attachment #2. Note the phasing between input and output, and also the fact that the gain is slightly lower than the expected gain of 31, because there are three poles at ~0.7 Hz, which already start showing some influence on the transfer function at 0.1 Hz.
  4. Noise measurement 
    • The whole point of this circuit is to realize sub 1pA/rtHz current noise to the coil, when it is connected.
    • For this test, no load was connected (i.e. voltage noise was measured at the output of the 25 kohm resistor), and the input was shorted to ground so that the DC value of the output was close to 0 (the idea was to not overload the SR560/SR785 with high voltage).
    • An SR560 preamp with gain x50 (DC coupled) was used to preamplify the signal. This was the maximum gain that could be used with the unit DC coupled, due to the small DC offset. I opted to keep the DC coupling to get a look at the low frequency noise as well, but in hindsight, maybe I should have used AC coupling as we only care about the current noise at ~100 Hz.
    • See Attachment #3 for results. The measurement is close to the model above ~100 Hz

Need to think more about how to better characterize this noise. An estimate of the required actuation can be found here.

    Reply  Sun Aug 23 23:36:58 2020, gautam, Update, Electronics, First look at HV coil driver IMG_5379.JPGstabilityCriterion.pdf

Summary:

A more careful analysis has revealed some stability problems. I see oscillations at frequencies ranging from ~600kHz to ~1.5 MHz, depending on the voltage output requested, of ~2 V pp at the high-voltage output in a variety of different conditions (see details). My best guess for why this is happening is insufficient phase margin in the open-loop gain of the PA95 high voltage amplification stage, which causes oscillations to show up in the closed loop. I think we can fix the problem by using a larger compensation capacitor, but if anyone has a better suggestion, I'm happy to consider it

Details:

The changes I wanted to make to the measurement posted earlier in this thread were: (i) to measure the noise with a load resistor of 20 ohms (~OSEM coil resistance) connected, instead of the unloaded config previously used, and (ii) measure the voltage noise on the circuit side (= TP5 on the schematic) with some high voltage output being requested. The point was to simulate conditions closer to what this board will eventually be used in, when it has to meet the requirement of <1pA/rtHz current noise at 100 Hz. The voltage divider formed by the 25 kohm series resistor and the 20 ohm OSEM coil simulated resistance makes it hopeless to measure this level of voltage noise using the SR785. On the other hand, the high voltage would destroy the SR785 (rated for 30 V max input). So I made a little Pomona box to alllow me to do this measurement, see Attachment #1. Its transfer function was measured, and I confirmed that the DC high voltage was indeed blocked (using a Fluke DMM) and that the output of this box never exceeded ~1V, as dictated by the pair of diodes - all seemed okay .

Next, I wanted to measure the voltage noise with ~10mA current flowing through the output path - I don't expect to require more than this amount of current for our test masses. However, I noticed some strange features in the spectrum (viewed continuously on the SR785 using exponential averaging setting). Closer investigation using an oscilloscope revealed:

  1. 600kHz to 1 MHz oscillations visible, depending on output voltage.
  2. The oscillations vanish if I drive output above +30 V DC (so input voltage > 1 V).
  3. The oscillations seem to be always present when the output voltage is negative.
  4. No evidence of this offset if circuit is unloaded and voltage across 25k resistor is monitored. But they do show up on scope if connected to circuit side even in this unloaded config.

Some literature review suggested that the capacitor in the feedback path, C4 on the schematic, could be causing problems. Specifically, I think that having that capacitor in the feeddback path necessitates the use of a larger compensation capacitor than the nominal 33pF value (which itself is higher than the 4.7pF recommended on the datasheet, based on experience of the ESD driver circuit which this is based on, oscillations were seen there too but the topology is a bit different). As a first test of this idea, I removed the feedback capacitor, C4 - this seemed to do the trick, the oscillations vanished and I was able to drive the output between the high voltage supply rails. However, we cannot operate in this configuration because we need to roll off the noise gain for the input voltage noise of the PA95 (~6 nV/rtHz at 100 Hz will become ~200 nV/rtHz, which I confirmed using the SR785). Using a passive RC filter at the output of the PA95 (a.k.a. a "snubber" network) is not an option because we need to sum in the fast actuation path voltage at the output of the 25 kohm resistor.

Some modeling confirms this hypothesis, see Attachment #2.  The quantity plotted is the open-loop gain of the PA95 portion of the circuit. If the phase is 0 degrees, then the system goes unstable.

So my plan is to get some 470pF capacitors and test this idea out, unless anyone has better suggestions? I guess usually the OpAmps are compensated to be unconditionally stable, but in this case maybe the power op-amp is more volatile?

Quote:

Need to think more about how to better characterize this noise. An estimate of the required actuation can be found here.

       Reply  Wed Aug 26 16:12:25 2020, gautam, Update, Electronics, Test mass coil current requirements coilCurrents.png

Attachment #1 is a summary of the current to each coil on the suspensions. The situation is actually a little worse than I remembered - several coils are currently drawing in excess of 10mA. However, most of this is due to a YAW correction, which can be fixed somewhat more easily than a PIT correction. So I think the circuit with a gain of 31 for an input range of +/-10 V, which gives us the ability to drive ~12mA per coil through a 25kohm series resistor, will still provide sufficient actuation range. As far as the HV supplies go, we will want something that can do +/- 350 V. Then the current to the coils will at most be ~50 mA per optic. The feedback path will require roughly the same current. The quiescent draw of each PA95 is ~10mA. So per SOS suspension, we will need ~150mA.

If it turns out that we need to get more current through the 25kohm series resistance, we may have to raise the voltage gain of the circuit. Reducing the series resistance isn't a good option as the whole point of the circuit is to be limited by the Johnson noise of the series resistance. Looking at these numbers, the only suspension on which we would be able to plug in a HV coil driver as is (without a vent to correct for YAW misalignment) is ITMY.


Update 2 Sep 2020 2100: I confirmed today that the number reported in the EPICS channel, and the voltage across the series resistor, do indeed match up. The test was done on the MC3 coil driver as it was exposed and I didn't need to disable any suspensions. I used a Fluke DMM to measure the voltage across the resistor. So there is no sneaky factor of 2 as far as the Acromag DACs are concerned (unlike the General Standards DAC).

       Reply  Tue Sep 1 15:39:04 2020, gautam, Update, Electronics, HV coil driver oscillations fixed testSetup.pdfHVampNoise_driven.pdf

Summary:

Increasing the compensation capacitance (470 pF now instead of 33 pF) seems to have fixed the oscillation issues associated with this circuit. However, the measured noise is in excess of the model at almost any frequency of relevance. I believe the problem is due to the way the measurement is done, and that we should re-do the measurement once the unit is packaged in a shielded environment.

Details:

Attachment #1 shows (schematically) the measurement setup. Main differences from the way I did the last round of testing are:

  1. A 20 ohm series resistor was connected between the high voltage output and ground to simulate the OSEM coil.
  2. The test was done under driven conditions (i.e. some non-zero input voltage) to better simulate conditions under which the circuit will be used.
  3. An Acromag XT1541 DAC was used to provide the input signal, to simulate more realistic operating conditions.
  4. A pomona box filter was used to block out the high voltage DC signal which would otherwise destroy the SR785.

Attachment #2 shows the measurement results:

  • Tests were done at a few different drive levels to check if there was any difference.
  • The difference between "Idrive=0mA" and "Input Grounded" traces is that in the former, the Acromag DAC was connected but putting out 0V, wheras in the latter, I shorted the input to the circuit ground.
  • Because the measurement was done at the output of the PA95, the Johnson noise of 25 kohms (~20 nV/rtHz) was manually summed in quadrature to all the measured traces.
  • The plotted spectra were collected in 3 spans, 0-200 Hz, 200Hz-1.8kHz, and 1.8kHz-14.6kHz. The input range was kept constant, so I'm not sure what to make of the discontinuity around 1.8 kHz. Maybe the comb of lines that were being picked up were distorting the spectra for lower frequencies?
  • The "Model" is only for the electronics noise of the circuit. The low-pass filtered noise of the Acromag should be totally negligible above 10 Hz, see here. The fact that there is little difference between the "Idrive=0mA" and "Input Grounded" traces further supports this claim.
  • The diodes in the Pomona box are also unlikely to be the culprit, because with this Pomona box connected to the SR785 and its input terminated with 50ohms, I don't see the comb of spectral lines.

I didn't capture the data, but viewing the high voltage output on an Oscilloscope threw up no red flags - the oscillations which were previously so evident were nowhere to be seen, so I think the capacitor switch did the trick as far as stability is concerned.

There is a large excess between measurement and model out to a few kHz, if this is really what ends up going to the suspension then this circuit is useless. However, I suspect at least part of the problem is due to close proximity to switching power supplies, judging by the comb of ~10 Hz spaced peaks. This is a frequent problem in coil driver noise measurements - previously, the culprit was a switching power supply to the Prologix GPIB box, but now a Linear AC-DC converter is used (besides, disconnecting it had no visible effect). The bench supplies providing power to the board, however, is a switching supply, maybe that is to blame? I think the KEPCO supplies providing +/-250 V are linear. I tried the usual voodoo of twisting the wires used to receive the signal, moving the SR785 away from the circuit board etc, but these measures had no visible effect either. 

Conclusions:

The real requirement of this circuit is that the current noise above 100 Hz be <1pA/rtHz. This measurement suggests a level that is 5x too high. But the problem is likely measurement related. I think we can only make a more informed conclusion after shielding the circuit better and conducting the test in a more electromagnetically quiet environment.

          Reply  Thu Oct 22 11:14:47 2020, gautam, Update, Electronics, HV coil driver packaged into 2U chassis HVampNoise_driven_chassis.pdfHVampNoise_dispUnits.pdfD1900163_measurementSetup.zip

I packaged the HV coil driver into a 2U chassis, hoping for better shielding from pickup. There is still considerable excess noise in measurement vs model around 100 Hz, see Attachment #1. The projected displacement noise from this noise contribution is shown in Attachment #2 - I've also plotted the contribution from the 4.5kohm (planned value for fast path series resistance) for comparison. Attachment #3 has some photos of the measurement setup so if someone sees some red flags, please let me know.

  • The noise was measured with the output load connected to a 20ohm load resistor, to simulate an OSEM.
  • The input signal was driven with an Acromag, to try and mimic the actual operating conditions as closely as possible (although the fast path input was left unconnected).
  • The KEPCO switching HV power supplies were used to power the unit.

I've run out of ideas to try and make the measurement cleaner - the presence of the rather prominent power line harmonics suggests that this is still not perfect, but what more shielding can we implement? I have to make the measurement on the circuit side of the 25 kohm series resistor, so I am using some Pomona minigrabbers to clip onto the leg of the wirewound resistor (see photos in Attachment #3), so that's not great maybe, but what's the alternative?

So if this is truly the noise of the circuit, then while it's an improvement on the current situaiton, it's unsatisfying that such a simple circuit can't match the design expectations. But how do we want to proceed?

             Reply  Thu Oct 22 13:04:42 2020, rana, Update, Electronics, HV coil driver packaged into 2U chassis 

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

                Reply  Thu Oct 22 22:01:53 2020, gautam, Update, Electronics, HV coil driver packaged into 2U chassis DACnoiseFilterGain.pdfDACnoiseFilterNoises.pdf

It's not so easy to directly measure this I think, because the filtering is rather aggressive. Attachment #1 shows the measured transfer function (dots) vs the model and Attachment #2 shows the noise. I think this checks out - but I can't definitively rule out some excess noise at 100 Hz from this stage. Because the gain of the HV stage is x31, we'd need a preamp with better than 1nV/rtHz to directly measure the noise I guess. The Acromag noise model in Attachment #2 is based on a measurement I describe here.

Quote:

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

                   Reply  Fri Oct 23 09:03:43 2020, anchal, Update, Electronics, HV coil driver packaged into 2U chassis 

Andrew made a battery-powered 0.7 nVrtHz input-referred noise pre-amplifier for gain of 200. That might help you.

Quote:

we'd need a preamp with better than 1nV/rtHz to directly measure the noise I guess.

RXA: 0.7 nV is OK if you're not interested in low noise measurements. Otherwise, we have the transformer coupled pre-amp from SRS which does 0.15 nV/rHz and the Rai Weiss FET amp which has 0.35 nV for high impedance sources.

             Reply  Thu Nov 12 14:55:35 2020, gautam, Update, Electronics, More systematic noise characterization powerSupplyNoise.pdfcoherence.pdf

Summary:

I now think the excess noise in this circuit could be coming from the KEPCO switching power supply (in fact, the supplies are linear, and specd for a voltage ripple at the level of <0.002% of the output - this is pretty good I think, hard to find much better).

Details:

All component references are w.r.t. the schematic. For this test, I decided to stuff a fresh channel on the board, with new components, just to rule out some funky behavior of the channel I had already stuffed. I decoupled the HV amplifier stage and the Acromag DAC noise filtering stages by leaving R3 open. Then, I shorted the non-inverting input of the PA95 (i.e. TP3) to GND, with a jumper cable. Then I measured the noise at TP5, using the AC coupling pomona box (although in principle, there is no need for this as the DC voltage should be zero, but I opted to use it just in case). The characteristic bump in the spectra at ~100Hz-1kHz was still evident, see the bottom row of Attachment #1. The expected voltage noise in this configuration, according to my SPICE model, is ~10 nV/rtHz, see the analysis note.

As a second test, I decided to measure the voltage noise of the power supply - there isn't a convenient monitor point on the circuit to directly probe the +/- HV supply rails (I didn't want any exposed HV conductors on the PCB) - so I measured the voltage noise at the 3-pin connector supplying power to the 2U chassis (i.e. the circuit itself was disconnected for this measurement, I'm measuring the noise of the supply itself). The output is supposedly differential - so I used the SR785 input "Float" mode, and used the Pomona AC coupling box once again to block the large DC voltage and avoid damage to the SR785. The results are summarized in the top row of Attachment #1.

The shape of the spectra suggests to me that the power supply noise is polluting the output noise - Koji suggested measuring the coherence between the channels, I'll try and do this in a safe way but I'm hesitant to use hacky clips for the High Voltage. The PA95 datasheet says nothing about its PSRR, and seems like the Spice model doesn't include it either. It would seem that a PSRR of <60dB at 100 Hz would explain the excess noise seen in the output. Typically, for other Op-Amps, the PSRR falls off as 1/f. The CMRR (which is distinct from the PSRR) is spec'd at 98 dB at DC, and for other OpAmps, I've seen that the CMRR is typically higher than the PSRR. I'm trying to make a case here that it's not unreasonable if the PA95 has a PSRR <= 60dB @100 Hz.

So what are the possible coupling mechanisms and how can we mitigate it?

  1. Use better power supply - I'm not sure how this spec of 10-50 uV/rtHz from the power supply lines up in the general scheme of things, is this already very good? Or can a linear power supply deliver better performance? Assuming the PSRR at 100 Hz is 60 dB and falls off as 1/f, we'd need a supply that is ~10x quieter at all frequencies if this is indeed the mechanism.
  2. Better grounding? To deliver the bipolar voltage rails, I used two unipolar supplies. The outputs are supposedly floating, so I connected the "-" input of the +300 V supply to the "+" input of the -300 V supply. I think this is the right thing to do, but maybe this is somehow polluting the measurement?
  3. Additional bypass capacitors? I use 0.1 uF, 700V DC ceramic capacitors as bypass capacitors close to the leads of the PA95, as is recommended in the datasheet. Can adding a 10uF capacitor in parallel provide better filtering? I'm not sure if one with compatible footprint and voltage rating is readily available, I'll look around.

What do the analog electronics experts think? I may be completely off the rails and imagining things here.


Update 2130: I measured the coherence between the positive supply rail and the output, under the same conditions (i.e. HV stage isolated, input shorted to ground). See Attachment #2 - the coherence does mirror the "bump" seen in the output voltage noise - but the coherence is. only 0.1,  even with 100 averages, suggesting the coupling is not directly linear - anyways, I think it's worth it to try adding some extra decoupling, I'm sourcing the HV 10uF capacitors now.

                Reply  Thu Nov 12 15:40:42 2020, Koji, Update, Electronics, More systematic noise characterization 

Yes. The datasheet has a recommendation circuit with 10uF caps. Companies are careful to show reproducible, reliably functional circuit examples on datasheets. So, if the caps are there you should try to replicate the design.

Quote:

Additional bypass capacitors? I use 0.1 uF, 700V DC ceramic capacitors as bypass capacitors close to the leads of the PA95, as is recommended in the datasheet. Can adding a 10uF capacitor in parallel provide better filtering? I'm not sure if one with compatible footprint and voltage rating is readily available, I'll look around.

                   Reply  Mon Nov 16 00:02:34 2020, rana, Update, Electronics, More systematic noise characterization 

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.

Quote:

Yes. The datasheet has a recommendation circuit with 10uF caps. Companies are careful to show reproducible, reliably functional circuit examples on datasheets. So, if the caps are there you should try to replicate the design.

Quote:

Additional bypass capacitors? I use 0.1 uF, 700V DC ceramic capacitors as bypass capacitors close to the leads of the PA95, as is recommended in the datasheet. Can adding a 10uF capacitor in parallel provide better filtering? I'm not sure if one with compatible footprint and voltage rating is readily available, I'll look around.

                      Reply  Wed Jan 20 10:13:06 2021, gautam, Update, Electronics, HV Power supply bypassing bypassCaps.pdfIMG_9079.jpgIMG_9078.jpgHVampNoise_driven_chassis.pdfprintCoilCurrents.pdf

Summary:

Installing 10uF bypass capacitors on the High Voltage power supply line for the HV coil driver circuit doesn't improve the noise. The excess bump around a few hundred Hz is still present. How do we want to proceed? 

Details

  • The setup is schematically shown in Attachment #1.
  • Physically, the capacitors were packaged into a box, see Attachment #2.
  • This box is installed between the HVPS and the 2U chassis in which the circuit is housed, see Attachment #3.
  • I measured the noise, (using the same setup as shown here to avoid exposing the SR785 input to any high voltage), for a variety of drive currents. To make a direct comparison, I took two sets of measurements today, one with the decoupling box installed and one without.
  • The results are shown in Attachment #4. You can see there is barely any difference between the two cases. I've also plotted the expected noise per a model, and the measured Johnson noise of one of the 25kohm resistors being used (Ohmite, wirewound). I just stuck the two legs of the resistor into the SR785 and measured the differential voltage noise. There is a slight excess in the measured Johnson noise compared to what we would expect from the Fluctuation Dissipation theorem, not sure if this is something to be worried about or if it's just some measurement artefact.

Discussion:

So what do we do about this circuit? For the production version, I can make room on the PCB to install two 10uF film capacitors on the board itself, though that's unlikely to help. I think we've established that 

  1. The excess noise is not due to the Acromag or the input Acromag noise filtering stage of the circuit, since the excess is present even when the input to the HV stage is isolated and shorted to ground.
  2. There was some evidence of coherence between the supply rails and the output of the HV stage (with input isolated and shorted to ground). The coherence had the "right shape" to explain the excess noise, but the maximum value was only ~0.1 (could have been because I was not measuring directly at the PA95's supply rail pins due to space constraints).
  3. The impedance of 10uF at 100Hz is ~150 ohms. idk what the impedance of the supply pins of the PA95 are at this frequency (this will determine the coupling of ripples in the HVPS output to the PA95 itself.

Do we have any better bipolar HV supply that I can use to see if that makes any difference? I don't want to use the WFS supplies as it's not very convenient for testing.


Not really related directly to this work but since we have been talking about current requirements, I attach the output of the current determining script as Attachment #5. For the most part, having 220ohm resistances on the new HAM-A coil driver boards will lead to ~half the DAC range being eaten up for the slow alignment bias. For things like MC1/MC3, this is fine. But for PRM/SRM/BS, we may need to use 100ohms. Chub has ordered all manner of resistances so we should have plenty of choices to pick from.

                         Reply  Mon Feb 1 12:30:21 2021, gautam, Update, Electronics, More careful characterization HVPS.pdfHV_testckt.pdftotalNoise.pdf

Summary:

  1. Swapping out the KEPCO HV supplies (linear) I was using for a pair of HP6209s I borrowed from Rich has improved the noise performance somewhat.
  2. However, there is still an excess relative to the model. I confirmed that this excess originates from the PA95 part of the circuit (see details).
  3. The bypass capacitors don't seem to have any effect on the measured ripple from these HP6209s. Maybe they're internally fitted with some 10uF or similar bypass caps?
  4. The production version of this board, with several improvements (after discussions with Koji and Rich), are on the DCC. They're being fabbed right now and will arrive in ~1 week for more bench testing. 

Power supply bypassing [updated 10pm]:

As mentioned earlier in this thread, I prepared a box with two 10uF, 1kV rated capacitors to bypass the high-voltage rails (see inset in the plot), to see if that improves the performance. However, in measuring the voltage ripple directly with the SR785 (no load connected), I don't see any significant difference whether the decoupling caps are connected or not, see Attachment #1. For this, and all other HV measurements made, I used this box to protect the SR785. One hypothesis is that this box itself is somehow introducting the excess noise, maybe because of leakage currents of the diode pair going into the 1Mohm SR785 input impedance, but I can't find any spec for this, and anyway, these diodes should be at ground potential once the transient has settled and the DC blocking capacitor has charged to its final value.

Note that the 10uF caps have an ESR of 7.2 mOhms. The HP6209 has a source impedance "<20mOhm" when operated as a CV source, per the datasheet. So perhaps this isn't so surprising? The same datasheet suggests the source impedance is 500 mOhms from 1kHz to 100 kHz, so we should see some improvement there, but I only measured out to 2 kHz, and I didn't take much effort to reduce these crazy peaks so maybe they are polluting the measurement out there. There must also be some continuous change of impedance, it cannot be <20 mOhm until 1 kHz and then suddenly increase to 500 mOhms. Anyways, for this particular circuit, the nosie DC-1kHz is what is important so I don't see a need to beat this horse more. 

Simplified circuit testing:

I decided to see if I can recover the spec'd voltage noise curve from the PA95 datasheet. For this, I configured the PA95 as a simple G=31 non-inverting amplifier (by not stuffing the 15 uF capacitor in the feedback path). Then, with the input grounded, I measured the output voltage noise on the circuit side of the 25kohm resistor (see inset in Attachment #2). To be consistent, I used the DC blocking box for this measurement as well, even though the output of the PA95 under these test conditions is 0V. Once again, there is considerable excess around ~100 Hz relative to a SPICE model. On the basis of this test, I think it is fair to say that the problem is with the PA95 itself. As far as I can tell, I am doing everything by the book, in terms of having gain > 10, using a sufficiently large compensaiton cap, HV rail decoupling etc etc. Note that the PA95 is a FET input opamp, so the effects of input current noise should be negligible. The datasheet doesn't provide the frequency dependence, but if this is just shot noise of the 1200 pA input bias current (for 300 V rails, per the spec), this is totally negligible, as confirmed by LTspice.

In the spirit of going step-by-step, I then added the feedback capacitor, and still, measured noise in excess of what I would expect from my model + SR785 measurement noise.

Integrated circuit testing:

After the above simplified test, I stuffed a full channel as designed, and tested the noise for various drive currents. To best simulate the operating conditions, an Acromag XT1541 was used to set the DC voltage that determines the drive current through the 25 kohm resistor. The measurements were made on the circuit side of this resistor (I connected a 20ohm resistor to ground to simulate the OSEM). As shown in Attachment #3, the noise with these HP6209 supplies is significantly better than what I saw with the KEPCO supplies, lending further credence to the hypothesis that insufficient PSRR is the root of the problem here. I've added subplots in a few different units - to be honest, I think that reaching this level of measured displacement noise at the 40m at 100 Hz would already be pretty impressive.

So what's next?

The main design change is that a passive R-C-R (4k-3uF-20k) replaces the single 25kohm resistor at the output of the PA95. 

  • This allows similar current drive range.
  • But adds an LPF to filter out the observerd excess noise at 100 Hz. 

Let's see if this fixes the issue. Not that I've also added a pair of input protection diodes to the input of the PA95 in the new design. The idea is that this would protect the (expensive) PA95 IC from, for example, the unit being powered with the +/- 18V rail but not the +/- 300 V rail. As I type this, however, I wonder if the leakage current noise of these diodes would be a problem. Once again, the datasheet doesn't provide any frequency dependence, but if it's just the shot noise of the 1nA expected when the diodes are not reverse biased (which is the case when the PA95 is operating normally since both inputs are at nearly the same potential), the level is ~20 fA/rtHz, comparable to the input current noise of the PA95, so not expected to be an issue. In the worst case, the PCB layout allows for this component to just be omitted. 

                         Reply  Wed Feb 10 21:14:03 2021, gautam, Update, Electronics, Production version of the HV coil driver tested inputDiffRecTF.pdfLVnoises.pdftotalNoise.pdftimeDomainTests.pdf

Summary:

I did what I consider to be a comprehensive set of tests on the production version of the high voltage coil driver circuit. I think the performance is now satisfactory and the circuit is ready for the production build. Barring objections from anyone, I will ask Chub to place an order for components to stuff the 4 necessary units + 1 spare on Friday, 12 Feb (so that people have a full day to comment). A big thanks to Chub and the folks at JLCPCB for dealing with my incessant order requests and patiently supporting this build and letting me turn this around in 10 days - hopefully this is the end of this particular saga.

Schematic is here. All references to component designations are for v4 of the schematic.

Important design changes:

  1. All I/O to this board will be via D9 connectors. This will allow bypassing the high voltage stage in future suspensions while retaining the same cable config in the suspension drive, if that is desired. Some re-arrangement of the grouping of coils was also done for consistency with the planned upgrade.
  2. Differential receiving for the input signal from the Acromag. The nominal quad opamp is LT1125 but if we find noise issues (which I didn't), the OP497 has compatible PCB footprint.
  3. Added input protection dual diode D6 to protect the PA95 as recommended in the datasheet. This should protect the IC if (for example) the HV line isn't plugged in but the Acromag input is non-zero.
  4. Increased the feedback resistance from 30kohms to 12kohms. R16 through R21 are now 20k, while the old design had 5k. The purpose is to reduce the current demand in the feedback path, hopefully this opens up the number of DCPS we can use. To keep the overall gain of 31, the resistor R15 was upped from 1kohms to 4kohms.
  5. Feedback capacitance reduced from 15 uF to 3 uF. This was largely for space saving / ease of layout on the PCB. The resulting corner frequency is increased slightly from 0.35 Hz to 0.45 Hz but this doesn't have any imapct on the performance of the circuit at frequencies of interest (1/2/pi/R/C had R=30k, C=15uF, now R=120k, C=3uF).
  6. Added an R-C-R network at the output of the PA95, before the fast actuation signal is summed and sent to the OSEM coil.
    • This is probably the most important change, noise-performance wise.
    • The purpose of the network is to passively filter out the excess noise we saw at ~100 Hz (the corner from the 4kohm resistor + 3uF cap is at ~13 Hz, so factor of 10 filtering at 100 Hz, which was deemed sufficient, see earlier elogs in the thread). 
    • The Johnson noise contribution of the 20 kohm resistor is slightly higher than the original design which had a 25 kohm series resistor (but no R-C-R passive filter at the output of the PA95). But once again, this was deemed to have negligible effect on the performance at frequencies of interest to us.
    • The total current driving capability of the circuit is almost unchanged since the 20kohm + 4kohm nearly equals the old 25kohm resistance.
  7. Made the Vmon paths for monitoring the HV output of the PA95 differential sending, seems like a good practise to follow for all new designs.
  8. Added on-board bypass capacitors (2 x 10uF WIMA film caps) for cleaning up the HV supply noise.

Tests:

A series of tests were done. Note that only 1 channel was stuffed (I am out of PA95s), and the HP power supplies borrowed from Rich were used for the HV rails. For the +/-18V, a regular bench-top unit was used.

  1. Low voltage stage tests
    • TF of the differential receiving stage was measured and the overall unity gain and corner at 24kHz were verified, see Attachment #1.
    • With the input of the circuit grounded, I measured the noise of the circuit at various points (see legends on Attachment #2). I didn't bother to do a detailed verification against a SPICE model as the levels seemed roughly what is expected.
  2. Overall noise performance with HV stage enabled
    • For a range of drive currents, generated by applying the appropriate voltage using an Acromag XT1541 DAC module to the J1 connector, I measured the voltage on the circuit side of the 20 kohm resistor (by clipping onto the resistor leg. Note that the path to ground for the current was provided by connecting a 20 ohm resistor between pins 1 and 6 on J3a, and then grounding pin 6.
    • Results are shown in Attachment #3
    • For the drive currents at the edge of the range of operation, there is a small excess relative to lower drive currents. My best hypothesis for why this is happening is that the HV rail is too close to the requested output voltage (the HP units are rated for 320V, which is borderline if we want 300V at the output of the PA95). In any case, the R-C-R passive filter means that above ~60 Hz, there is excellent agreement between model and measurement.
  3. Time domain tests
    • Used a function generator. to drive a 50 mHz, 3Vpp sine wave to the "Bias Input" (=J1), and monitored (i) pickoff of drive signal, (ii) High voltage output at the circuit side of the 20kohm resistor, and (iii) the Vmon output (=pins 1/6 on J4), all on a 100 MHz Tektronix scope.
    • Results shown in Attachment #4. Once again, I see no red flags.
    • While I had the unit hooked up to the scope, I also checked the time domain signal with the scope set to 100 ns/div time base. I saw no evidence of any oscillatory features, either when no input signal was applied, or when a DC signal was provided (in which case the scope was set to AC coupling). 👍 
  4. Checked that the protection diodes at various locations in the circuit work.
  5. Checked the pin-mapping on all 6 D9 connectors is consistent with the top level diagram in the schematic.

PCB remarks:

As I was stuffing the board, I noticed a few improvements that can be made. Just noting these here for documentation purposes - these changes are mostly aesthetic and I personally see no need to order another set of PCBs.

  1. In some places, the silkscreen designators don't have the correct "orientation" relative to the component they are designating. I didn't find any serious ambiguity in terms of being misled to stuff the wrong component onto the wrong pads, but in the spirit of doing a professional job...
  2. The current limiting resistors on the +/-430V LEDs (R37/R38) have footprints for leaded components rather than SMT (which is what the +/-15V LEDs have).
  3. R45 and R46, the current limiting resistors for the rear panel power indicator LEDs, have 0805 footprint rather than 1206.
  4. When I drew up the PCB, R23, the 4kohm resistor in the R-C-R network, was set up as a 1W resistor. Let's say there can be 15 mA flowing through this resistor - the power dissipated is 15e-3 ^2 * 4e3 is 0.9W, which is uncomfortably close to the limit. For all the tests above, I used a 3W resistor, and didn't find any serious noise issues. The drilled holes are a little tight for this higher power rated resistor, but I don't think this is a showstopper.

Communications with Apex:

I've been talking to support at Apex, and pointed out that I couldn't match the SPICE model performance even for a simple non-inverting amplifier with the PA95. The feedback I got from them was that 

  1. They don't optimize the SPICE models for input noise and so it was a nice coincidence that model and measurement are somewhat close (but not exactly).
  2. They recommend the PA194, which is actually advertised as "low-noise". The PA95 is apparently not a "low-noise" part, with its 2uVrms input noise. 

Whiel the PA194 is compatible with our voltage and current requirements for this application, it is ~3x the cost, and seems like the R-C-R output filter allows us to realize the goal of 1pA/rtHz, so I'm inclined to stick with the PA95.

Production assembly:

I'd prefer to get as much of the board stuffed by Screaming Circuits as possible. It took me ~3 hours to stuff 1 channel + the power supply parts, standoffs etc. So I estimate it'll take me ~6 hours to stuff the entire board. So not the end of the world if we have to do it in-house.

                            Reply  Fri Feb 26 16:31:02 2021, gautam, Update, Electronics, Production version of the HV coil driver tested with KEPCO HV supplies totalNoise_KEPCO.pdf

Koji asked me to test the production version of the coil driver with the KEPCO HV supplies. See Attachment #1 for the results. For comparison, I've added a single trace from the measurements made with the HP supplies. I continue to see excess noise with the KEPCO supplies. Note that in the production version of the board that was tested, there are a pair of 10uF bypass capacitors on the board for the HV supply lines. It is possible that one or both KEPCO supplies are damaged - one was from the ASY setup and one I found in the little rack next to 1X2. The test conditions were identical to that with the HP supplies (as best as I could make it so).

                               Reply  Fri Feb 26 20:20:43 2021, Koji, Update, Electronics, Production version of the HV coil driver tested with KEPCO HV supplies 

This is very disappointing. Even with KEPCO linear supply with the improved HV driver circuit, the noise level is significantly higher than the 20kOhm R thermal noise.

What is special with the HP supplies? Can you replace KEPCOs with the HP supply, one by one to specify which one is making the noise bad?

                                  Reply  Sat Feb 27 17:25:42 2021, gautam, Update, Electronics, Production version of the HV coil driver tested with KEPCO HV supplies 

I will try the test of switching out KEPCOs one at a time for the HP. Given that the passive RC filter doesn't filter out the excess, I am wondering if the KEPCO is somehow polluting the circuit ground? The measurement was made between the circuit side of R24 (see schematic) and a ground testpoint, so the passive R23/C15 pole should filter the noise above ~15 Hz.

Quote:

This is very disappointing. Even with KEPCO linear supply with the improved HV driver circuit, the noise level is significantly higher than the 20kOhm R thermal noise.

What is special with the HP supplies? Can you replace KEPCOs with the HP supply, one by one to specify which one is making the noise bad?

                                     Reply  Thu May 20 16:56:21 2021, Koji, Update, Electronics, Production version of the HV coil driver tested with KEPCO HV supplies P_20210520_154523_copy.jpg

HP HV power supply ( HP6209 ) were returned to Downs

Entry  Wed May 12 14:23:20 2021, Jordan, Update, SUS, Mass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units Moments_of_Inertia_SI.PNG
 
    Reply  Wed May 12 16:53:59 2021, Koji, Update, SUS, Mass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units 

No, this is the property of the suspension assembly. The mass says 10kg

Could you do the same for the testmass assembly (only the suspended part)? The units are good, but I expect that the values will be small. I want to keep at least three significant digits.

       Reply  Wed May 12 17:06:52 2021, Jordan, Update, SUS, Mass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units Moments_of_Inertia_SI.PNG

Here are the mass properties for the only the test mass assembly (optic, 3" ring, and wire block). (Updated with g*mm^2)

Quote:

No, this is the property of the suspension assembly. The mass says 10kg

Could you do the same for the testmass assembly (only the suspended part)? The units are good, but I expect that the values will be small. I want to keep at least three significant digits.

 

          Reply  Wed May 19 18:29:41 2021, Koji, Update, SUS, Mass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units SOS_resonant_freq.pdfSOS_resonant_freq.nb.zip

Calculation for the SOS POS/PIT/YAW resonant frequencies

- Nominal height gap between the CoM and the wire clamping point is 0.9mm (cf T970135)

- To have the similar res freq for the optic with the 3" metal sleeve is 1.0~1.1mm.
As the previous elog does not specify this number for the current configuration, we need to asses this value and the make the adjustment of the CoM height.

Entry  Wed Apr 21 19:28:03 2021, Anchal, Update, PSL, PSL/IFO recovery 

[Anchal, Koji]

Removed the top sheet

  • Opened first from the door side so that any dust would spill outside.
  • Then rolled the sheet inward to meet in the middle.
  • Repeated this twice for the 2 HEPA filters.

Removed the sheets on the table

  • Lifted sheet up making sure the top side face outside always.
  • Rolled it sideways halfway through.
  • Cut down the sheet vertically.
  • Slided the doors to the other side and rolled the remaining half.
  • On the door side, the sheets above the ALS optics were simply lifted off.

Restarting PSL

  • Turned on the HEPAs at the max speed
  • Switched on laser to jsut above the threshold
    • Before the 1st eom, power was 20mW 
    • After the EOM/AOM, 18mW. So about 90% transmission through all polarizing optics.
    • We saw the resonances of the PMC but could not lock it even with highest gain available (30 dB).
  • Increased the input power to PMC to 100mW
    • Locked the PMC at 30dB gain
    • The transmitted power was ~50-60 mW. (Had to use power meter suspended by hand only.
    • The right before the IMC (after the 2nd EOM) 48mW. So none of the alignment was lost.
  • Opened the PSL shutter.
  • We were able to see IMC reflection signal.
  • We were also able to see IMC catching lock as the servo was left ON earlier.
  • Switched off the servo.
  • Decided to increase the power while watching PMC Trans/Refl and IMC REFL
  • Injection diode current to innolight was increased slowly to 2.10A. Saw a mod hopping region aroun 1.8A.
  • We recovered the PMC Trans >0.7 V.
  • PZT was near the edge, so moved by one FSR.
  • The PMC refelction signal is still shown in red at around 48 mV.

Back to control room

  • IMC was locked almost immediately by manually finding the lock while keeping IMC WFS off to preserve the offsets from yesterday.
  • Then switch on IMC WFS. Working good.
  • Then unlocked the servo and switched on IMC Autolocker. Lock was caught immediately.

Decided to start locking the arms

  • The arm transmissions were flashing but at 0.2~0.3 level.
  • Decided to adjust TT1 and TT2 Pitch and Yaw to align the light going into the arms.
  • This made TRY ~0.6 / TRX ~0.8 at the peak of the flashing
  • Locked the arms. (By switching on C1:LSC-MODE_SELECT which engages all servos).
  • Used ASS to align Yarm then align Xarm. Procedure:
    • Sitemap > ASC > c1ass
    • Open striptool to look at progress. ! Scripts YARM > striptool.
    • Switch on ASS. ! More Scripts > ON
    • Wait for the TRY to reach to around 0.97.
    • Freeze the outputs. ! Scripts > Freeze Outputs.
    • Offload the offsets to preserve the output. ! More Scripts > OFFLOAD OFFSETS.
    • Switch off ASS. ! More Scripts > OFF
    • Repeted this for XARM.
  • At the end, both XARM and YARM were locked with TRX ~ 0.97 and TRY ~ 0.96.
    Reply  Wed Apr 21 19:43:20 2021, Koji, Update, PSL, New HEPA speed control P_20210421_193637.jpgP_20210421_193627.jpg

The new HEPA speed controllers are attached at the middle of the HEPA unit (not at the edge of the unit)... (Attachment 1)
You still need a step./stool to touch the knob and need a ladder for a more precise setting.

We still don't know the optimal speed of the nominal IFO operation. For now, the HEPAs are running at the max speed (Attachment 2).
Once we know the optimal setting, we mark the knobs so that we can see them only with the step.

       Reply  Thu Apr 22 14:41:55 2021, Chub, Update, PSL, New HEPA speed control 40M_PSL_HEPA.jpg

When adjusting the blower speed, give the blower at least 30 seconds to speed up or slow down to the set speed.  The flywheel effect of the big motor armature and blower mass requires time to follow the control current.  Note the taller Flanders HEPA filters.  These and the new intake filters should keep the PSL air clean for a long time!

Quote:

The new HEPA speed controllers are attached at the middle of the HEPA unit (not at the edge of the unit)... (Attachment 1)
You still need a step./stool to touch the knob and need a ladder for a more precise setting.

We still don't know the optimal speed of the nominal IFO operation. For now, the HEPAs are running at the max speed (Attachment 2).
Once we know the optimal setting, we mark the knobs so that we can see them only with the step.

 

          Reply  Fri Apr 23 18:00:02 2021, gautam, Update, PSL, HEPA speed lowered HEPAdiag.pdf

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.

             Reply  Fri Apr 23 19:26:58 2021, Koji, Update, PSL, HEPA speed lowered 

I believe that there is an internal setting for the minimum flow, so the flow is not linear ("0%" is not zero), but we should mark this flow speed once you find this is sufficiently low for the locking too.

             Reply  Fri May 14 17:45:05 2021, rana, Update, PSL, HEPA speed raised 

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

                Reply  Tue May 18 00:52:38 2021, rana, Update, PSL, HEPA speed raised Untitled.png

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.

                   Reply  Tue May 18 20:26:11 2021, rana, Update, PSL, HEPA speed raised 

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.

    Reply  Thu Apr 22 15:15:26 2021, gautam, Update, PSL, PMC 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.

       Reply  Thu Apr 22 15:34:54 2021, Anchal, Update, PSL, PMC transmission 

Koji mentioned that the mode of the laser is different for lower diode currents. So that might be the reason why we got less transmission at the low input power but more afterward.

Entry  Sat May 15 12:39:54 2021, gautam, Update, PSL, NPRO tripped/switched off NPRO.png

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.

Entry  Fri May 14 03:29:50 2021, Koji, Update, Electronics, HV Driver noise test with the new HV power supply from Matsusada HV_Driver_PSD.pdf

I believe I did the identical test with the one in [40m ELOG 15786]. The + input of PA95 was shorted to the ground to exclude the noise from the bias input. The voltage noise at TP6 was measured with +/-300V supply by two HP6209 and two Matsusada R4G360.

With R4G360, the floor level was identical and 60Hz line peaks were less. It looks like R4G360 is cheap, easier and precise to handle, and sufficiently low noise.

Entry  Thu Apr 29 11:51:27 2021, Anchal, Summary, LSC, Start of measuring IMC WFS noise contribution in ar cavity length noise 

Tried locking the arms

  • Ran IFO > Configure > ! (YARM) > Restore YARM. Nothing happened.
  • Trying to align through tip-tilt:
    • Previous values: TT1: PIT: -1.7845, YAW: -0.2775; TT2: PIT: -1.3376, YAW: -0.0436
    • Couldn't get flashing of light in the arms at all.
    • Restored values to previous values.
  • Noticed that ITMY OPLEV YAWW Error has gone very high overnight while other oplevs remained the same.
  • Trying to change the C1:SUS-ITMY_YAW_OFFSET to bring this oplev yaw error back to near zero.
  • Changed C1:SUS-ITMY_YAW_OFFSET from -34 to 50. OPLEV_YEROR reduced to around -23 from -70.
  • Same thing with BS PIT. OPLEV_PERROR is highlighted in red at -52.
  • Changing C1:SUS-BS_PIT_OFFSET from 55 to 30. This brought OPLEV_PERROR to -15 from -52.
  • Trying to align PRM by changing C1:SUS-PRM_PIT_OFFSET and C1:SUS-PRM_YAW_OFFSET.
  • Inital values: C1:SUS-PRM_PIT_OFFSET: -20 , C1:SUS-PRM_YAW_OFFSET: 39.

Did the WFS step response test on IMC in between while waiting for help. See 16094.


Back to trying arm locking

  • Tried IFO > Configure > ! (XARM) > Restore YARM. Nothing happened.
  • Tried IFO > Configure > ! (YARM) > Restore YARM. Nothing happened again.
  • Tried Movie Capture of AS screen from VIDEO > Movie Capture > AS. But the script failed due to module not present error.

PMC got unlocked

  • Infront of me, PMC got unlocked. I did not go to PMC locking the screen at all since morning.
  • I opened the C1PSL_PMC screen. The PSL Autolocker blinker is not blinking but the switch is set to Enable. 
  • I do not see any automatic effort happening for regaining lock at PMC.
  • I'll try it manually. I was able to get the PMC locked again. C1:PSL-PMC_PMCTRANSPD is showing 0.761 V and C1:PSL-PMC_RFPDDC is showing 0.053 V.
  • Now IMC auto locker seems to be trying to get the lock acquired.
  • It acquired a lock a few times but struggled to keep it on. I reduced C1:IOO-WFS_GAIN to 0 and then the lock could stay on. Seemed like the accumulated offsets were not good.
  • So I cleared the history on WFS1, TRANS and WFS2 filter banks and then ramped the WFS overall gain (C1:IOO-WFS_GAIN) back to 1 and now IMC seems to stay locked in a stable configuration.
  • However, I still don't know what caused the PMC to get unlocked in the first place. Did my repeated arm locking attempts did something to the main laser frequency?

Back to trying arm locking

  • Tried IFO > Configure > ! (YARM) > Restore YARM again. Nothing happened again.
    Reply  Thu Apr 29 15:11:33 2021, gautam, Update, CDS, RFM  RFM_errs.pngScreenshot_2021-04-29_15-12-56.png

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.

       Reply  Thu Apr 29 17:43:16 2021, Koji, Update, CDS, RFM  

The other day I felt hot at the X end. I wondered if the Xend A/C was off, but the switch right next to the SP table was ON (green light).
I could not confirm if the A/C was actually blowing or not.

       Reply  Thu Apr 29 17:43:48 2021, Anchal, Update, CDS, F2A Filters double check F2AFiltersON.png

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?

Quote:

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.

          Reply  Fri Apr 30 00:20:30 2021, gautam, Update, CDS, F2A 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

    Reply  Thu Apr 29 17:51:19 2021, Anchal, Summary, LSC, Start of measuring IMC WFS noise contribution in arm cavity length noise WFS1_PIT_exc_80-100Hz_Arms_ASD.pdf

t Both arms were locked simply by using IFO > Configure > ! (YARM) > Restore YARM. I had to use ASS to improve the TRX/TRY to ~0.95.

I measured C1:LSC-XARM_IN1_DQ and C1:LSC-YARM_IN1_DQ while injecting band limited noise in C1:IOO-WFS1_PIT_EXC using uniform noise with amplitude 1000 along with filter defined by string: cheby1("BandPass",4,1,80,100). I calibrated the control arms signals by 2.44 nm/cts calibration factor directly picked up from 13984.

For the duration of this test, all LIMIT switches in the WFS loops were switched OFF.

I do not see any affect on the arm control signal power spectrums with or without the noise injection. Attachement 1 shows the PSD along with PSD of the injection site IN2 signal. I must be doing something wrong, so would like feedback before I go further.

       Reply  Fri Apr 30 00:18:40 2021, gautam, Summary, LSC, Start 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.

       Reply  Mon May 3 09:14:01 2021, Anchal, Paco, Update, LSC, IMC WFS noise contribution in arm cavity length noise WFS1_PIT_Noise_Inj_Test_IMC_unlocked.pdfWFS1_PIT_Noise_Inj_Test_ARM_locked.pdf

Lock ARMs

  • Try IFO Configure ! Restore Y Arm (POY) and saw XARM lock, not YARM. Looks like YARM biases on ITMY and ETMY are not optimal, so we slide C1:SUS-ETMY_OFF from 3.0 --> -14.0 and watch Y catch its lock.
  • Run ASS scripts for both arms and get TRY/TRX ~ 0.95
    • We ran X, then Y and noted that TRX dropped to ~0.8 so we ran it again and it was well after that. From now on, we will do Y, then X.

WFS1 noise injection

  • Turn WFS limits off by running switchOffWFSlims.sh
  • Inject broadband noise (80-90 Hz band) of varying amplitudes from 100 - 100000 counts on C1:IOO-WFS1_PIT_EXC
  • After this we try to track its propagation through various channels, starting with
    • C1:LSC-XARM_IN1_DQ / C1:LSC-YARM_IN1_DQ
    • C1:SUS-ETMX_LSC_OUT_DQ / C1:SUS-ETMY_LSC_OUT_DQ
    • C1:IOO-MC_F_DQ
    • C1:SUS-MC1_**COIL_OUT / C1:SUS-MC2_**COIL_OUT / C1:SUS-MC3_**COIL_OUT
    • C1:IOO-WFS1_PIT_ERR / C1:IOO-WFS1_YAW_ERR
    • C1:IOO-WFS1_PIT_IN2

** denotes [UL, UR, LL, LR]; the output coils.

  • Attachment 1 shows the power spectra with IMC unlocked
  • Attachment 2 shows the power spectra with the ARMs (and IMC) locked
          Reply  Mon May 3 17:28:58 2021, Anchal, Paco, Rana, Update, LSC, IMC WFS noise contribution in arm cavity length noise excitationoftheMCanglessothatwecanseesomethingdotpng.pngexcitationoftheMCanglessothatwecanseesomethingdotpngbutthistimeitsMC2.png

Rana came and helped us figure us where to inject the noise. Following are the characteristics of the test we did:

  • Inject normal noise at C1:IOO-MC1_PIT_EXC using AWGGUI.
  • Excitation amplitude of 54321 in band 12-37Hz with Cheby1 8th order bandpass filter with same limits.
  • Look at power spectrum of C1:IOO-MC_F_DQ, C1:IOO-WFS1-PIT_OUT_DQ and the C1:IOO-MC1_PIT_EXC itself.
  • Increased the gain of the noise excitation until we see some effect in MC_F.
  • Diaggui also showed coherence plot in the bottom, which let's us have an estimate of how much we need to go further.

Attachment 1 shows a screenshot with awggui and diaggui screens displaying the signal in both angular and longitudinal channels.

Attachment 2 shows the analogous screenshot for MC2.

 

             Reply  Tue May 4 11:43:09 2021, Anchal, Paco, Update, LSC, IMC WFS noise contribution in arm cavity length noise ArmCavNoiseContributions.pdfIOO-MC1_PIT_NoiseInjTest2.pdfIOO-MC1_PIT_NoiseInjTest_AWGGUI_Config.png

We redid the WFS noise injection test and have compiled some results on noise contribution in arm cavity noise and IMC frequency noise due to angular noise of IMC.


Attachment 1: Shows the calibrated noise contribution from MC1 ASCPIT OUT to ARM cavity length noise and IMC frequency noise.

  • For calibrating the cavity length noise signals, we sent 100 cts 100Hz sine excitation to ITMX/Y_LSC_EXC, used actuator calibration for them as 2.44 nm/cts from 13984, and measured the peak at 100 hz in time series data. We got calibration factors: ETMX-LSC_OUT: 60.93 pm/cts , and ETMY-LSC_OUT: 205.0 pm/cts.
  • For converting IMC frequency noise to length noise, we used conversion factor given by \lambda L / c where L is 37.79m and lambda is wavelength of light.
  • For converting MC1 ASCPIT OUT cts data to frequency noise contributed to IMC, we sent 100,000 amplitude bandlimited noise (see attachment 3 for awggui config) from 25 Hz to 30 Hz at C1:IOO-MC1_PIT_EXC. This noise was seen at both MC_F and ETMX/Y_LSC_OUT channels. We used the noise level at 29 Hz to get a calibration for MC1_ASCPIT_OUT to IMC Frequency in Hz/cts. See Attachment 2 for the diaggui plots.
  • Once we got the calibration above, we measured MC1_ASCPIT_OUT power spectrum without any excitaiton and multiplied it with the calibration factor.
  • However, something must be wrong because the MC_F noise in length units is coming to be higher than cavity length noise in most of the frequency band.
    • It can be due to the fact that control signal power spectrum is not exactly cavity length noise at all frequencies.  That should be only above the UGF of the control loop (we plan to measure that in afternoon).
    • Our calibration for ETMX/Y_LSC_OUT might be wrong.
                Reply  Fri May 7 11:54:02 2021, Anchal, Paco, Update, LSC, IMC WFS noise contribution in arm cavity length noise ITMX-XARM_TF.pdfITMY-YARM_TF.pdfArmCavNoiseContributions.pdf

We today measured the calibration factors for XARM_OUT and YARM_OUT in nm/cts and replotted our results from 16117 with the correct frequency dependence.


Calibration of XARM_OUT and YARM_OUT

  • We took transfer function measurement between ITMX/Y_LSC_OUT and X/YARM_OUT. See attachment 1 and 2
  • For ITMX/Y_LSC_OUT we took calibration factor of 3*2.44/f2 nm/cts from 13984. Note that we used the factor of 3 here as Gautum has explicitly written that the calibration cts are DAC cts at COIL outputs and there is a digital gain of 3 applied at all coil output gains in ITMX and ITMY that we confirmed.
  • This gave us callibration factors of XARM_OUT: 1.724/f2 nm/cts , and YARM_OUT: 4.901/f2 nm/cts. Note the frrequency dependence here.
  • We used the region from 70-80 Hz for calculating the calibration factor as it showed the most coherence in measurement.

Inferring noise contributions to arm cavities:

  • For converting IMC frequency noise to length noise, we used conversion factor given by \lambda L / c where L is 37.79m and lambda is wavelength of light.
  • For converting MC1 ASCPIT OUT cts data to frequency noise contributed to IMC, we sent 100,000 amplitude bandlimited noise  from 25 Hz to 30 Hz at C1:IOO-MC1_PIT_EXC. This noise was seen at both MC_F and ETMX/Y_LSC_OUT channels. We used the noise level at 29 Hz to get a calibration for MC1_ASCPIT_OUT to IMC Frequency in Hz/cts. This measurement was done in 16117.
  • Once we got the calibration above, we measured MC1_ASCPIT_OUT power spectrum without any excitaiton and multiplied it with the calibration factor.
  • Attachment 3 is our main result.
    • Page 1 shows the calculation of Angle to Length coupling by reading off noise injects in MC1_ASCPIT_OUT in MC_F. This came out to 10.906/f2 kHz/cts.
    • Page 2-3 show the injected noise in X arm cavity length units. Page 3 is the zoomed version to show the matching of the 2 different routes of calibration.
    • BUT, we needed to remove that factor of 3 we incorporated earlier to make them match.
    • Page 4 shows the noise contribution of IMC angular noise in XARM cavity.
    • Page 5-6 is similar to 2-3 but for YARM. The red note above applied here too! So the factor of 3 needed to be removed in both places.
    • Page 7 shows the noise contribution of IMC angular noise in XARM cavity.

Conclusions:

  • IMC Angular noise contribution to arm cavities is atleast 3 orders of magnitude lower then total armc cavity noise measured.

Edit Mon May 10 18:31:52 2021

See corrections in 16129.

                   Reply  Mon May 10 18:19:12 2021, Anchal, Paco, Update, LSC, IMC WFS noise contribution in arm cavity length noise, Corrections ArmCavNoiseContributions.pdf

A few corrections to last analysis:

  • The first plot was not IMC frequency noise but actually MC_F noise budget.
    • MC_F is frequency noise in the IMC FSS loop just before the error point where IMC length and laser frequency is compared.
    • So, MC_F (in high loop gain frequency region upto 10kHz) is simply the quadrature noise sum of free running laser noise and IMC length noise.
    • Between 1Hz to 100 Hz, normally MC_F is dominated by free running laser noise but when we injected enough angular noise in WFS loops, due to Angle to length coupling, it made IMC length noise large enough in 25-30 Hz band that we started seeing a bump in MC_F.
    • So this bump in MC_F is mostly the noise due to Angle to length coupling and hence can be used to calculate how much Angular noise normally goes into length noise.
  • In the remaining plots, MC_F was plotted with conversion into arm length units but this was wrong. MC_F gets suppressed by IMC FSS open loop gain before reaching to arm cavities and hence is hardly present there.
  • The IMC length noise however is not suppresed until after the error point in the loop. So the length noise (in units of Hz calculated in the first step above) travels through the arm cavity loop.
  • We already measured the transfer function from ITMX length actuation to XARM OUT, so we know how this length noise shows up at XARM OUT.
  • So in the remaining plots, we plot contribution of IMC angular noise in the arm cavities. Note that the factor of 3 business still needed to be done to match the appearance of noise in XARM_OUT and YARM_OUT signal from the IMC angular noise injection.
  • I'll post a clean loop diagram soon to make this loopology clearer.
                      Reply  Wed May 12 10:53:20 2021, Anchal, Paco, Update, LSC, PSL-IMC PDH Loop and XARM PDH Loop diagram IMC_SingleArm.pdf

Attached is the control loop diagram when main laser is locked to IMC and a single arm (XARM) is locked to the transmitted light from IMC.

Quote:
 
  • I'll post a clean loop diagram soon to make this loopology clearer.

 

Entry  Mon May 10 10:57:54 2021, Anchal, Paco, Summary, Calibration, Using ALS beatnote for calibration, test BeatY_ITMY_CalibrationAt57Hz.pdfBeatY_ITMY_CalibrationAt43Hz.pdfBeatY_ITMY_CalibrationAt77Hz.pdf

Test details:

  • We locked both arms and opened the shutter for Yend green laser.
  • After toggling the shutter on.off, we got a TEM00 mode of green laser locked to YARM.
  • We then cleared the phase Y history by clicking "CLEAR PHASE Y HISTROY" on C1LSC_ALS.adl (opened from sitemap > ALS > ALS).
  • We sent excitation signal at ITMY_LSC_EXC using awggui at 43Hz, 77Hz and 57Hz.
  • We measured the power spectrum and coherence of C1:ALS-BEATY_FINE_PHASE_OUT_HZ_DQ and C1:SUS-ITMY_LSC_OUT_DQ.
  • The BEATY_FINE_PHASE_OUT_HZ is already calibrated in Hz. This we assume is done by multip[lying the VCO slope in Hz/cts to the error signal of the digital PLL loop that tracks the phase of beatnote.
  • We calibrated C1:SUS-ITMY_LSC_OUT_DQ by multiplying with
    \large 3 \times \frac{2.44 \, nm/cts}{f^2} \times \frac{c}{1064\,nm \times 37.79\, m} = \frac{54.77}{f^2} kHz/cts where f is in Hz.
    The 2.44/f2 nm/cts is taken from 13984.
  • We added the calibration as Poles/zeros option in diaggui using gain=54.577e3 and poles as "0, 0".
  • We found that ITMY_LSC_OUT_DQ calibration matches well at 57Hz but overshoots (80 vs 40) at 43 Hz and undershoots (50 vs 80) at 77Hz.

Conclusions:

  • If we had DRFPMI locked, we could have used the beatnote spectrum as independent measurement of arm lengths to calibrate the interferometer output.
  • We can also use the beatnote to confirm or correct the ITM actuator calibrations. Maybe shape is not exactly 1/f2 unless we did something wrong here or the PLL bandwidth is too short.
Entry  Thu May 6 16:13:39 2021, Anchal, Summary, IMC, Angular actuation calibration for IMC mirrors IMC_Ang_Act_Cal_Kakeru_Tests.pdf

Here's my first attempt at doing angular actuation calibration for IMC mirrors using the method descibed in /users/OLD/kakeru/oplev_calibration/oplev.pdf by Kakeru Takahashi. The key is to see how much is the cavity mode misaligned from the input mode of beam as the mirrors are moved along PIT or YAW.

There two possible kinds of mismatch:

  • Parallel displacement of cavity mode axis:
    • In this kind of mismatch, the cavity mode is simply away from input mode by some distance \large \beta.
    • This results in transmitted power reduction by the gaussian factor of \large e^{-\frac{\beta^2}{w_0^2}} where \large w_0 is the beam waist of input mode (or nominal waist of cavity).
    • For some mismatch, we can approximate this to
                                                                               \large 1 - \frac{\beta^2}{w_0^2}
  • Angular mismatch of cavity mode axis:
    • The cavity mode axis could be tilted with respect to input mode by some angle \large \alpha.
    • This results in transmitted power reduction by the gaussian factor of \large e^{- \frac{\alpha^2}{\alpha_0^2}}  where \large \alpha_0 is the beam divergence angle of input mode (or nominal waist of cavity) given by \large \frac{\lambda}{\pi w_0}.
    • or some mismatch, we can approximate this to
                                                                                \large 1 - \frac{\alpha^2}{\alpha_0^2}

Kakeru's document goes through cases for linear cavities. For IMC, the mode mismatches are bit different. Here's my take on them:

MC2:

  • MC2 is the easiest case in IMC as it is similar to the end mirror for linear cavity with plane input mirror (the case of which is already studies in sec 0.3.2 in Kaker's document).
  • PIT:
    • When MC2 PIT is changed, the cavity mode simple shifts upwards (or downwards) to the point where the normal from MC2 is horizontal.
    • Since, MC1 and MC3 are plane mirrors, they support this mode just with a different beam spot position, shifted up by \large (R-L)\theta.
    • So the mismatch is simple of the first kind. In my calculations however, I counted the two beams on MC1 and MC3 separately, so the factor is twice as much.
    • Calling the coefficient to square of angular change \large \eta, we get:
                                     \large \eta_{._{2P}} = \frac{2 (R-L)^2}{w_0^2}
    • Here, R is radius of curvature of MC1/3 taken as 21.21m and L is the cavity half-length of IMC taken as 13.545417m.
  • YAW:
    • For YAW, the case is bit more complicated. Similar to PIT, there will be a horizontal shift of the cavity mode by \large (R-L)\theta.
    • But since the MC1 and MC3 mirrors will be fixed, the angle of the two beams from MC1 and MC3 to MC2 will have to shift by \large \theta/2.
    • So the overall coefficient would be:
                                     \large \eta_{._{2Y}} = \frac{2 (R-L)^2}{w_0^2} + \frac{2}{4\alpha_0^2}
    • The factor of 4 in denominator of seconf term on RHS above comes because only half og angular actuation is felt per arm. The factor of 2 in numerator for for the 2 arms.

MC1/3:

  • First, let's establish that the case of MC1 and MC3 is same as the cavity mode must change identically when the two mirrors are moved similarly.
  • YAW:
    • By tilting MC1 by \large \theta, we increase the YAW angle between MC1 and MC3 by \large \theta.
    • Beam spot on both MC1 and MC3 moves by \large (R-L)\theta.
    • The beam angles on both arms get shifted by \large \theta/2.
    • So the overall coefficient would be:
                                     \large \eta_{._{13Y}} = \frac{2 (R-L)^2}{w_0^2} + \frac{2}{4\alpha_0^2}
    • Note, this coefficient is same as MC2, so it si equivalent to moving teh MC2 by same angle in YAW.
  • PIT:
    • I'm not very sure of my caluculation here (hence presented last).
    • Changing PIT on MC1, should change the beam spot on MC2 but not on MC3. Only the angle of MC3-MC2 arm should deflect by \large \theta/2.
    • While on MC1, the beam spot must change by \large (R-L)\theta/2 and the MC1-MC2 arm should deflect by \large \theta/2.
    • So the overall coefficient would be:
                                     \large \eta_{._{13P}} = \frac{(R-L)^2}{4 w_0^2} + \frac{2}{4\alpha_0^2}

Test procedure:

  • We first clicked on MC WFS Relief (on C1:IOO-WFS_MASTER) to reduce the large offsets accumulated on WFS outputs. This script took 10 minutes and reduced the offsets to single digits and IMC remained locked throughout the process.
  • Then we switched off the WFS to freeze the outputs.
  • We moved the MC#_PIT/YAW_OFFSET up and down and measured the C1:IOO-MC_TRANS_SUMFILT_OUT channel as an indicater of IMC mode matching.
  • Attachement 1 are the 6 measurements and there fits to a parabola. Fitting code and plots are thanks to Paco.
  • We got the curvature of parabolas \large \gammafrom these fits in units of 1/cts^2.
  • The \large \eta coefficients calculated above are in units of 1/rad^2.
  • We got the angular actuation calibration from these offsets to physical angular dispalcement in units of rad/cts by \large \sqrt{\gamma / \eta}.
  • AC calibration:
    • I parked the offset to some value to get to the side of parabola. I was trying to reduce transmission from about 14000 cts to 10000-12000 cts in each case.
    • Sent excitation using MC#_ASCPIT/YAW_EXC using awg at 77 Hz and 10000 cts.
    • Measured the cts on transmission channel at 77 Hz. Divided it by 2 and by the dc offset provided. And divided by the amplitude of cts set in excitation. This gives \large \eta_{ac} analogous to above DC case.
    • Then angular actuation calibration at 77 Hz from these offsets to physical angular dispalcement in units of rad/cts by \large \sqrt{\gamma/\eta_{ac}}.
  • Following are the results:
    Optic Act
    Calibration factor at DC [µrad/cts]
    Calibration factor at 77 Hz [prad/cts]
    MC1 PIT 7.931+/-0.029 906.99
    MC1 YAW 5.22+/-0.04 382.42
    MC2 PIT 13.53+/-0.08 869.01
    MC2 YAW 14.41+/-0.21 206.67
    MC3 PIT 10.088+/-0.026 331.83
    MC3 YAW 9.75+/-0.05 838.44

     


  • Note these values are measured with the new settings in effect from 16120. If these are changed, this measurement will not be valid anymore.
  • I believe the small values for MC1 actuation have to do with the fact that coil output gains for MC1 are very weird and small, which limit the actuation strength.
  • TAbove the resonance frequencies, they will fall off by 1/f^2 from the DC value. I've confirmed that the above numbers are of correct order of magnitude atleast.
  • Please let me know if you can point out any mistakes in the calculations above.
Entry  Wed May 5 13:05:07 2021, Chub, Update, General, chassis delivery from De Leone de_leone_del_5-5-21.jpg

Assembled chassis from De Leone placed in the 40 Meter Lab, along the west wall and under the display pedestal table.  The leftover parts are in smaller Really Useful boxes, also on the parts pile along the west wall.

Entry  Tue May 4 19:14:43 2021, Yehonathan, Update, General, OSEMs from KAGRA 

I put the box containing the untested OSEMs from KAGRA near the south flow bench on the floor.

Entry  Mon May 3 18:59:58 2021, Anchal, Summary, General, Weird gas leakagr kind of noise in 40m control room 40mNoiseFinal.mp3

For past few days, a weird sound of decaying gas leakage comes in the 40m control room from the south west corner of ceiling. Attached is an audio capture. This comes about every 10 min or so. 

    Reply  Mon May 3 23:28:56 2021, Koji, Summary, General, Weird gas leakagr kind of noise in 40m control room 

I also noticed some sound in the control room. (didn't open the MP3 yet)

I'm afraid that the hard disk in the control room iMac is dying.

 

Entry  Mon Apr 19 09:17:51 2021, Jordan, Update, VAC, Empty N2 Tanks N2_Pressure.PNG

When I came into the lab this morning, I noticed that both N2 tanks were empty. I had swapped one on Friday (4-16-21) before I left the lab. Looking at the logs, the right tank (T2) sprung a leak shortly shortly after install. I leak checked the tank coupling after install but did not see a leak. There could a leak further down the line, possibly at the pressure transducer.

The left tank (T1) emptied normally over the weekend, and I quickly swapped the left tank for a full one, and is curently at ~2700 psi. It was my understanding that if both tanks emptied, V1 would close automatically and a mailer would be sent out to the 40m group. I did not receive an email over the weekend, and I checked the Vac status just now and V1 was still open.

I will keep an eye on the tank pressure throughout the day, and will try to leak check the T2 line this afternoon, but someone should check the vacuum interlocks and verify.

 

    Reply  Wed Apr 21 12:56:00 2021, Jordan, Update, VAC, Empty N2 Tanks Screenshot_2021-04-21_12-53-26.png

Installed T2 today, and leaked checked the entire line. No issues found. It could have been a bad valve on the tank itself. Monitored T2 pressure for ~2 hours to see if there was any change. All seems ok.

Quote:

When I came into the lab this morning, I noticed that both N2 tanks were empty. I had swapped one on Friday (4-16-21) before I left the lab. Looking at the logs, the right tank (T2) sprung a leak shortly shortly after install. I leak checked the tank coupling after install but did not see a leak. There could a leak further down the line, possibly at the pressure transducer.

The left tank (T1) emptied normally over the weekend, and I quickly swapped the left tank for a full one, and is curently at ~2700 psi. It was my understanding that if both tanks emptied, V1 would close automatically and a mailer would be sent out to the 40m group. I did not receive an email over the weekend, and I checked the Vac status just now and V1 was still open.

I will keep an eye on the tank pressure throughout the day, and will try to leak check the T2 line this afternoon, but someone should check the vacuum interlocks and verify.

 

 

       Reply  Wed Apr 28 11:31:40 2021, Jon, Update, VAC, Empty N2 Tanks 

I checked out what happened on c1vac. There are actually two independent monitoring codes running:

  1. The interlock service, which monitors the line directly connected to the valves.
  2. A seaparate convenience mailer, running as a cronjob, that monitors the tanks.

The interlocks did not trip because the low-pressure delivery line, downstream of the dual-tank regulator, never fell below the minimum pressure to operate the valves (65 PSI). This would have eventually occurred, had Jordan been slower to replace the tanks. So I see no problem with the interlocks.

On the other hand, the N2 mailer should have sent an email at 2021-04-18 15:00, which was the first time C1:Vac-N2T1_pressure dropped below the 600 PSI threshold. N2check.log shows these pressures were recorded at this time, but does not log that an email was sent. Why did this fail? Not sure, but I found two problems which I did fix:

  • One was that the code was checking the sensor on the low-pressure side (C1:Vac-N2_pressure; nominally 75 PSI) against the same 600 PSI threshold as the tanks. This channel should either be removed or a separate threshold (65 PSI) defined just for it. I just removed it from the list because monitoring of this channel is redundant with the interlock service. This does not explain the failure to send an email.
  • The second issue was that the pyN2check.sh script appeared to be calling Python 3 to run a Python 2 script. At least that was the situation when I tested it, and this was causing it to fail partway through. This might well explain the problem with no email. I explicitly set python --> python2 in the shell script.

The code then ran fine for me when I retested it. I don't see any further issues.

Quote:

Installed T2 today, and leaked checked the entire line. No issues found. It could have been a bad valve on the tank itself. Monitored T2 pressure for ~2 hours to see if there was any change. All seems ok.

Quote:

When I came into the lab this morning, I noticed that both N2 tanks were empty. I had swapped one on Friday (4-16-21) before I left the lab. Looking at the logs, the right tank (T2) sprung a leak shortly shortly after install. I leak checked the tank coupling after install but did not see a leak. There could a leak further down the line, possibly at the pressure transducer.

The left tank (T1) emptied normally over the weekend, and I quickly swapped the left tank for a full one, and is curently at ~2700 psi. It was my understanding that if both tanks emptied, V1 would close automatically and a mailer would be sent out to the 40m group. I did not receive an email over the weekend, and I checked the Vac status just now and V1 was still open.

I will keep an eye on the tank pressure throughout the day, and will try to leak check the T2 line this afternoon, but someone should check the vacuum interlocks and verify.

 

Entry  Mon Apr 26 18:52:52 2021, Anchal, Paco, HowTo, Computer Scripts / Programs, awg free slot 

Today we had some trouble launching an excitation on C1:IOO-MC_LSC_EXC from awggui. The error read:

awgSetChannel: failed getIndexAWG C1:SUS-MC2_LSC_EXC ret=-3

What solved this was the following :

  1. launch the dtt command line interface
  2. Anchal remembers a slot number 37008
  3. We issue >> awg free 37008
  4. Slot freed, launch a new instance of awggui
Entry  Tue Apr 13 20:45:16 2021, Yehonathan, Update, PSL, Laser amplifier 20210413_204721.jpg20210413_203300.jpg20210413_204940.jpg20210413_205549.jpg

{Yehonathan, Rana}

We unpacked the content of the amplifier crate in front of the water fountain (see attachments). Inside we found:

1. Amplifier head. (attachment 1)
2. Amplifier electronics and pump diodes (attachment 2).
3. Optical fiber (attachment 3).
4. 2 Long water hoses (~2m) and 2 short ones.
5. Network cable.
6. A wooden plate.
7. Cable sleeve (attachment 2)?
8. Some manuals will be uploaded to the wiki soon.

Please don't move/touch any of that stuff

Things that we need to consider/obtain:
1. A suitable power cable (attachment 4) with suitable power ratings (800W according to the amplifier specs). The connector head is C19 I believe.
2. A chiller. Rana says Aidan knows where to find one. Should we chill the amplifier head as well?
3. A mounting plate for the amplifier head with good thermal conductivity.
4. The pump wavelength is 808nm, we need to get suitable safety goggles.
5. Where to put the big electronics box. Preferably on 1X1 or 1X2.
6. How do we arrange the different components on the table? We also need to mode match the beam into the amplifier.

 

    Reply  Wed Apr 14 19:48:18 2021, gautam, Update, PSL, Laser 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. 

       Reply  Thu Apr 15 09:46:24 2021, Yehonathan, Update, PSL, Laser amplifier 

Some more relevant documents provided by Matt:

Phase III:70W amplifier integration at LIGO

70W amplifier External Shutter

aLIGO PSL high power attenuator

 

          Reply  Fri Apr 16 18:21:36 2021, Yehonathan, Update, PSL, Laser amplifier 20210416_143642.jpg20210416_145408.jpg20210416_145448.jpg20210416_181324.jpg

I surveyed a bit the 1X1/2 area to plan for the installation of the laser amplifier.

There is a vacancy at the bottom of 1X2 (attachment 1). I measured the dimensions of the diode box (DB) and it should fit. The optical fiber bundle is 75m long and should reach the amplifier head on the table easily.

According to the specs, the maximum power consumption of the DB is 800W (typically 600W), it should probably have its own circuit breaker. It can easily draw more than a few amps. The rack power strips are connected to this 4 socket box (attachment 2), is this just another power strip? It is connected to a circuit breaker with a 30A rating. How do we proceed from here?

In any case, we will need at least 2 meters of power cable.

I also tried to find a suitable place for a water chiller. A few suggestions are in the attachments. Basically either between the electronics shelves and the small rack next to 1X2 or next to the small rack close to the optical table. Maybe put it where the ladder sits and find another place for the ladder. Other options?

We would also need a windows machine running the Beckhoff software. The idea is that all the different laser components (DB, chillers, interlocks, switches) are connected to the EtherCat (over the ethernet infrastructure) so that the Beckhoff code can recognize a failure and switch off everything.

The things that are monitored:

1. Is the NPRO on?

2. Is the flow rate from the chillers enough?

3. Is the temperature of the diodes in the normal range?

4. Is one of the interlocks open?

5. Was one of the emergency buttons pushed?

6. Was the key switch on the DB turned to OFF?

The DB is EtherCat ready but the rest of the signals need to be interfaced somehow. Do we have to buy these EtherCAT terminals?

 

 

             Reply  Sun Apr 18 21:29:55 2021, rana, Update, PSL, Laser amplifier 
  • 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.
                Reply  Wed Apr 21 11:09:57 2021, yehonathan, Update, PSL, Laser amplifier 20210420_171606.jpg20210420_171621.jpg20210420_171611.jpg20210420_171629.jpg20210420_171702.jpg

I went to the TCS lab to take a look at the chillers lying around. I spotted two chillers:

1. Thermoflex1400 (attachment 1,2). Spec sheet.

2. Polyscience Recirculator 6000 series (attachment 3,4). Manual.

The Thermoflex has various communication ports. The Recirculator doesn't have any communication ports, but it is connected to a flow meter with what seems to be an electronic readout (attachment 5). Manual.

Both chillers have similar capacity ~ 4 gallons/minute. Thermoflex has 2 times more reservoir capacity than the Recirculator.

None of them seem to be Bechkoff-ready.

I guess we can have interlock code handling mixed signals Beckhoff+Non beckhoffs?

                   Reply  Thu Apr 22 17:28:34 2021, Yehonathan, Update, PSL, Laser amplifier 20210422_124940.jpgDrillRoomSchematics.pdf20210422_125240_1.png

According to the aLIGO 70W amplifier interlock concept the flow rate of the chiller should be between 5 and 40 l/min. The chillers I found in the TCS lab both have around 15 l/min flow rate so we should be fine in that regard.

Assuming that the power consumption of the diode box is ~800W and that the optical output power of the diode is ~ 300W of optical power, the chillers need to be able to remove the remaining power. At room temperature, they both have enough cooling capacity according to their specs.

As for the idea to put the chiller and diode box in the drill room: There are not a lot of options here. The only viable place is the SW corner (attachment 1). I was told this place is used sometimes for liquid nitrogen dewar. Alternatively, if possible, we can move the fire extinguishers to the SW corner and use the NW corner. In that way, we don't have to clear all the junk from the SW corner, as long as the extinguishers are still accessible.

I made a sketch (attachment 2) showing a possible setup for a diode box + chiller rack. The fiber and network cable can go through the hole in the wall that already exists for the N2. It will have to get bigger though (attachment 3). The rack would also need to host some Acromag unit to convert the communication channel of the chiller/flow meter to Ethernet. The Acromag on 1X7 has no spare channels.

The only power socket in the room, to which the drill is connected, is circuit #36 which is connected to panel L in the lab. The breaker's ampacity seems to be 20A if I'm reading the number on the breaker correctly.

 

Entry  Thu Apr 22 14:49:08 2021, gautam, Update, Computer Scripts / Programs, rossa 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.

Entry  Thu Apr 22 01:42:38 2021, Koji, Summary, Electronics, HV Supply Comparison HV_Supply_PSD_H.pdfHV_Supply_PSD_K.pdfHV_Supply_PSD_M.pdfHV_Supply_PSD.pdf

New HV power supply from Company 'M' has been delivered. So I decided to compare the noise levels of some HV supplies in the lab. There are three models from companies 'H', 'K', and 'M'.

The noise level was measured with SR785 via Gautam's HP filter with protection diodes.

'H' is a fully analog HV supply and the indicator is analog meters.
'K' is a model with a LCD digital display and numerical keypad.
'M' is a model with a knob and digital displays.

All the models showed that the noise levels increased with increased output voltage.

Among these three, H showed the lowest noise. (<~1uV/rtHz@10Hz and <50nV/rtHz@100Hz) (Attachment 1)

K is quite noisy all over the measured freq range and the level was <50uV/rtHz. Also the PSD has lots of 5Hz harmonics. (Attachment 2)

M has a modest noise level (<~30uV/rtHz@10Hz and <1uV/rtHz@100Hz)except for the noticeable line noise (ripple). (Attachment 3)

The comparison of the three models at 300V is Attachment 4. The other day Gautam and I checked the power spectrum of the HV coil driver with KEPCO and the output noise level of the coil driver was acceptable. So I expect that we will be able to use the HV supply from Company M. Next step is to check the HV driver noise with the model by M used as the supply.

Entry  Wed Apr 21 05:48:47 2021, Chub, Update, General, PSL HEPA Maintenance 

Yikes!  That's ONE filter.  I'll get another from storage.

    Reply  Wed Apr 21 13:10:12 2021, Koji, Update, General, PSL HEPA Maintenance 

It's probably too late to say but there are/were two boxes. (just for record)

 

Entry  Wed Apr 21 10:59:07 2021, rana, Summary, Cameras, note on new GigE cam @ 1064 

Note from Stephen on more sensitive Baslers.

Entry  Wed Apr 21 00:08:15 2021, Koji, Update, PSL, PSL Table (sort of) covered / HEPA "chimney" 20210420235324_IMG_0560.jpeg20210420235304_IMG_0559.jpeg20210420235243_IMG_0558.jpeg20210420235344_IMG_0562.jpeg

Shutdown Procedure:
PSL Shutter closed / MC Autolocker disabled / PSL mechanical shutter closed / Laser injection current turned to zero / Laser turn off (red button) / Laser key turned off

The laser stat before the shutdown:
- LD Temp A: Set 22.07 (Untouched)
- LD Temp B: Set 21.03(Untouched)
- Laser Injection Current: Dial 9.53, Actual 2.100 -> Dial was moved to zero upon shutting down
- Laser Crystal Temp: Dial 3.34 (untouched)  Set 30.57 Actual 30.60 (Untouched)

PSL Table covering

- Because of the so many cables going up and down, sealing the PSL table with the metalized sheet was not easy. Therefore, the sheets have been just softly laid above the optics. (Attachment 1)
- The largest sheet which covers the east half of the table was taped to the table at the bottom, so that the air from the chimneys (see below) does not come up to the table

- The large dust could come from the opening of the enclosure during the filter replacement. So it was considered to be easier to seal the openings. (Attachment 2)
- Of course, the HEPAs are going to be tested after the maintenance work. It means that vent paths were needed so that the seals do not explode with the pressure (together with dust).
- Thus, the tubes of the sheets are attached to the seals to form "chimneys" for guiding the airflow beneath the table. (Attachment 2/3/4)
- This configuration was not meant to be sufficiently strong for a continuous run of the fans. Long running of the HEPAs may cause the failure of the seal tapes.
  Therefore the HEPA test should be done with a low flow rate and/or a short period of high flow.

- Once the work has been done, all the sheets should be carefully removed without scattering the fallouts onto the optics.

 

    Reply  Wed Apr 21 01:14:03 2021, Koji, Update, PSL, PSL Table (sort of) covered / HEPA "chimney" P_20210421_005056.jpgP_20210421_005114.jpgP_20210421_005302.jpg

I also located the (possible) HEPA filters in the lab. (Attachments 1~3)

Oh! This is NO-NO! We can't place anything in front of the mains breakers. (Attachment 2)
I relocated the objects (Attachment 3)

 

Entry  Fri Apr 16 00:21:52 2021, Koji, Update, General, Glue Freezer completely frozen P_20210416_000906.jpgP_20210416_000850.jpg

I was looking at the laser head/amp and somehow decided to open the glue freezer. And it was stuck. I've managed to open it but the upper room was completely frozen.
Some of the batteries were embedded in a block of ice. I think we should throw them out.

Can the person who comes in the morning work on defrosting?

- Coordinate with Yehonathan and move the amps and the wooden crate so that you can move the freezer.

- Remove the contents to somewhere (it's OK to be room temp for a while)

- Unplug the freezer

- Leave the freezer outside with the door open. After a while, the ice will fall without care.

- At the end of the day, move it back to the lab. Continue defrosting the other day if the ice remains.

    Reply  Fri Apr 16 10:58:16 2021, Yehonathan, Update, General, Glue Freezer completely frozen 20210416_105048.jpg

{Paco, Anchal, Yehonathan}

We emptied the fridge and moved the amplifier equipment on top of the amplifier crate. We unplugged the freezer and moved it out of the lab to defrost (attachment).

Quote:

I was looking at the laser head/amp and somehow decided to open the glue freezer. And it was stuck. I've managed to open it but the upper room was completely frozen.
Some of the batteries were embedded in a block of ice. I think we should throw them out.

Can the person who comes in the morning work on defrosting?

- Coordinate with Yehonathan and move the amps and the wooden crate so that you can move the freezer.

- Remove the contents to somewhere (it's OK to be room temp for a while)

- Unplug the freezer

- Leave the freezer outside with the door open. After a while, the ice will fall without care.

- At the end of the day, move it back to the lab. Continue defrosting the other day if the ice remains.

 

       Reply  Fri Apr 16 19:07:31 2021, Yehonathan, Update, General, Glue Freezer completely frozen 

There is still a huge chunk of unmelted ice in the fridge. I moved the content of that fridge in the main fridge and put "do not eat" warning signs.

I returned the fridge to the lab and plugged it back in to prevent flooding.

Defrosting will have to continue on Monday.

          Reply  Mon Apr 19 10:52:27 2021, Yehonathan, Update, General, Glue Freezer completely frozen 

{Anchal, Paco, Yehonathan}

We took the glue fridge outside.

             Reply  Mon Apr 19 19:40:54 2021, Yehonathan, Update, General, Glue Freezer completely frozen 

{Paco, Yehonathan}

We broke the last chunk of ice and cleaned the fridge. We move the fridge back inside and plugged it into the wall. The glues were moved back from the main fridge.

The batteries that were found soaking wet are now somewhat dry and were left on the cabinet drawers for future recycling.

Quote:

{Anchal, Paco, Yehonathan}

We took the glue fridge outside.

 

Entry  Fri Apr 16 11:31:00 2021, rana, Update, elog, elog stuck ~10 AM today 

found it unresponsive. Restarted fine using procedure documented in wiki

Entry  Thu Apr 15 18:33:39 2021, Koji, Update, CDS, More 16bit ADC adapter boards P_20210415_183139_1.jpg

We received 10x 16bit ADC adapter boards from Todd. S2100687~S2100696

The number of soldered resistors seems to be less than that on the schematics. They are related to duotone, so check if it's OK upon use.

Entry  Wed Apr 7 22:48:48 2021, gautam, Update, IOO, Waveplate commissioning remotePowCtrl.pdf

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.

    Reply  Tue Apr 13 17:47:07 2021, gautam, Update, IOO, Waveplate commissioning - software prepared remoteHWP.png

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. 

       Reply  Thu Apr 15 15:54:46 2021, gautam, Update, IOO, Waveplate 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?

Entry  Wed Apr 14 23:55:34 2021, gautam, Update, Electronics, HV 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.

Entry  Wed Apr 14 14:52:42 2021, gautam, Update, General, IFO State IFOSTATE.png

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

    Reply  Wed Apr 14 16:46:24 2021, Anchal, Update, General, IFO State 

That makes sense. I assumed that IFO-STATE is configured as you have proposed it to be configured. This could be implemented in later.

Quote:
 

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

 

Entry  Wed Apr 14 12:27:10 2021, gautam, Update, General, Lab 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.

    Reply  Wed Apr 14 13:12:13 2021, Anchal, Update, General, Sorry, it was me 

Sorry about that. It must be me. I'll make sure it doesn't happen again. I was careless to not check back, no further explanation.indecision

       Reply  Wed Apr 14 15:30:29 2021, rana, Update, General, Sorry, it was me 

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?

Entry  Wed Mar 17 09:05:01 2021, Paco, Anchal, Configuration, Computers, 40m Control Room Changes 
  • Switched positions of allegra and donatella.
  • While doing so, the hdmi cable previously used by donatella snapped. We replaced this cable by another unused cable we found connected only on one end to rossa. We should get more HDMI cables if that cable was in use for some other purpose.
  • Paco bought a bluetooth speaker/mic that is placed infront of allegra and it's usb adapter is connected to iMac's keyboard in the bottom. With the new camera installed, the 40m video call environment is now complete.
  • Again, we have placed allegra's monitor for place holder but it is not working and we need new monitors for it in future whenever it is going to be used.
    Reply  Wed Apr 14 13:16:20 2021, Anchal, Configuration, Computers, 40m Control Room Changes 
  • I have confirmed that the old two monitors' backlighting is not working. One can see the impression of the display without any brightness on them. Both old monitors are on the shelf behind.
  • Today we got a monitor and mouse from Mike. I had to change /etc/default/grub GRUB_GFXMODE to 1920x1200@30 on allegra for it to work with the(any) monitor.
  • Allegra is Debian 10 with latest cds-workstation installed on it. It is a good test station to migrate our existing scripts to start using updated cds-workstation configuration.
Quote:
  • Again, we have placed allegra's monitor for place holder but it is not working and we need new monitors for it in future whenever it is going to be used.

 

Entry  Tue Apr 13 19:24:45 2021, gautam, Update, PSL, High power operations intensityDist.pdfclippingLoss.pdf

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.

Entry  Mon Apr 12 08:32:54 2021, Anchal, Paco, Summary, PSL, PMC unlocked at 2pm on Sunday; ~ Restored 

PMC lost lock between 21:00 and 22:00 UTC on April 11th as seen in the summary pages:

https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20210411/psl/#gallery-4

That's between 2pm and 3pm on Sunday for us. We're not sure what caused it. We will attempt to lock it back.


Mon Apr 12 08:45:53 2021: we used milind's python script in scripts/PSL/PMC/pmc_autolocker.py. It locked the PMC in about a minute and then IMC catched lock succefully.

However, the PMC transmission PD shows voltage level of about 0.7V. On medm, it is set to turn red below 0.7 and yellow above. In Summary pages in the past, it seems like this value has typically been around 0.74V. Simil;arly, the reflection RFPD DC voltage is around 0.063 V right now while it is supposed to be around 0.04 nominally So the lock is not so healthy.

We tried running this script and the bashscript version too (scripts/PSL/PMC/PMCAutolocker) a couple of times but it was unable to acquire lock.

Then we manually tried to acquire lock by varying the C1:PSL-PMC_RAMP (with gain set to -10 dB) and resetting PZT position by toggling Blank. After a few attempts, we were able to find the lock with transmission PD value around 0.73V and reflection RFPD value around 0.043. PZT control voltage was 30V and shown in red in medm to begin with. So we adjusted the output ramp again to let it come to above 50V (or maybe it just drifted to that value by itself as we could se some slow drift too). At Mon Apr 12 09:50:12 2021 , the PZT voltage was around 58V and shown in green.

We assume this is a good enough point for PMC lock and move on.

    Reply  Mon Apr 12 18:34:26 2021, Yehonathan, Summary, PSL, PMC unlocked at 2pm on Sunday; ~ Restored 

PMC lost lock again at around 16:00 April 12. I was able to lock it again but the transmission is only 0.6 now and REFL is 0.14.

Rana came in and realigned the PMC stirring mirrors. Now the transmission is 0.757V, and the REFL is 0.03V.

I noticed that the PZT was around 250V. Given that the PMC got unlocked at 16:00, which is around the peak temperature time in the lab (lagging behind the outside weather), due to the PZT voltage going down to 0V, I figured that the PZT voltage would go up during the night when the lab gets cold and therefore will likely go out of range again.

I found a different working point at 150V and relocked the PMC.

 

Entry  Thu Apr 8 20:58:17 2021, Koji, Update, CDS, ADC adapter boards assembly P_20210408_205411_2_1.jpg

5x 16bit ADC adapter boards (D0902006) assembled.

Entry  Wed Apr 7 13:07:03 2021, Jordan, Update, SUS, CoM on 3"->2" Adapter Ring for SOS CoM_with_Chamfer.pngMoments_of_Inertia.PNG

Adding the chamfer around the edge of the optic ring did not change the center of mass relative to the plane from the suspension wires.

The CoM was .0003" away from the plane. Adding the chamfer moved it closer by .0001". See the attached photo.

I've also attached the list of the Moments of Inertia of the SOS Assembly.

Entry  Wed Apr 7 02:50:49 2021, Koji, Update, SUS, Flange Inspections 

Basically I went around all the chambers and all the DB25 flanges to check the invac cable configurations. Also took more time to check the coil Rs and Ls.

Exceptions are the TTs. To avoid unexpected misalignment of the TTs, I didn't try to disconnect the TT cables from the flanges.

Upon the disconnection of the SOS cables, the following steps are taken to avoid large impact to the SOSs

  • The alignment biases were saved or recorded.
  • Gradually moved the biases to 0
  • Turned off the watchdogs (thus damping)

After the measurement, IMC was lock and aligned. The two arms were locked and aligned with ASS. And the PRM alignment (when "misalign" was disengaged) was checked with the REFL CCD.
So I believe the SOSs are functioning as before, but if you find anything, please let me know.
 

Entry  Thu Oct 15 20:00:23 2020, Koji, Summary, General, HEPA AC cord replacement P_20201015_200732.jpgP_20201015_200752.jpgP_20201015_202615.jpgP_20201015_204234.jpg

The AC cord from the PSL HEPA variac to the junction box was replaced.
Now the HEPA is running at 70%


Showed up at the 40m at 7pm

Preparation

  • Closed the PSL shutter.
  • Closed the innolight shutter
  • Turned off the HEPA mains switch
  • Checked the HEPA fan rating: 115V 4.5A.
  • Brought the thickest power cord from the wall stock: the rating is 125V 15A. This should sufficiently hold two HEPAs.

Cable Replacing

  • Rechecked the wire connection. The new cord has green/black/white wires. And the colors agree with the color of the wires in the junction box.
  • Removed the existing cord.
  • Attached the new cord.
  • Checked the variac AC plug. The terminals in the plug look normal and the AC plug looked sufficiently rigid.
  • Checked the connection again. = OK

Testing

  • Turned on the HEPA mains switch
  • VairAC turned to 70%
  • Checked the air flow - The HEPA fans are sucking the air = OK

Closing the work

  • Closed the junction box.
  • Cleaned up the roof
  • Opend the innolight shutter
  • Opened the PSL shutter
  • Locked the PMC
  • Locked the IMC  - found the transmission was ~80% of the pre-work due to misalignment of the PMC
  • Aligned the PMC - this recovered the IMC REFL of ~5.2 when the IMC was unlocked

Leaving the 40m at 9:30pm

Memo: 40m wiring/Mask/Camera/Red Pitaya/Particle Counter

    Reply  Thu Apr 1 23:55:33 2021, Koji, Summary, General, HEPA AC cord replacement 

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.

       Reply  Fri Apr 2 15:17:23 2021, gautam, Summary, General, HEPA 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.

          Reply  Tue Apr 6 21:17:04 2021, Koji, Summary, General, PSL HEPA investigation 20210406211741_IMG_0554.jpeg20210406211840_IMG_0555.jpeg20210406211850_IMG_0556.jpeg

- Last week we found both of the PSL HEPA units were not running.

- I replaced the capacitor of the north unit, but it did not solve the issue. (Note: I reverted the cap back later)
- It was found that the fans ran if the variac was removed from the chain.
- But I'm not certain that we can run the fans in this configuration with no attendance considering fire hazard.

@3AM: UPON LEAVING the lab, I turned off the HEPA. The AC cable was not warm, so it's probably OK, but we should wait for the continuous operation until we replace the scorched AC cable.


The capacitor replacement was not successful. So, the voltages on the fan were checked more carefully. The fan has the three switch states (HIGH/OFF/LOW). If there is no load (SW: OFF), the variac out was as expected. When the load was LOW or HIGH, it looked as if the motor is shorted (i.e. no voltage difference between two wires).

I thought the motors may have been shorted. But if the load resistance was measured with the fluke meter, it showed some resistance

- North Unit: SW LOW 4.6Ohm / HIGH 6.0Ohm
- South Unit: SW LOW 6.0Ohm / HIGH 4.6Ohm (I believe the internal connection is incorrect here)

I believed the motors are alive! Then the fans were switched on with the variac removed... they ran. So I set the switch LOW for the north unit and HIGH for the south unit.

Then I inspected the variac:

  • The AC output has some liquid leaking (oil?) (Attachment 1)
  • The AC plug on the variac out has a scorch mark (Attachments 2/3)

So, this scorched AC plug/cable connected directly to the AC right now. I'm not 100% confident about the safety of this configuration.
Also I am not sure what was wrong with the system.

  • Has the variac failed first? Because of the heat? I believe that the HEPA was running @30% most of the time. Maybe the damage was already there at the failure in Nov 2020?
  • Or has the motor stopped at some point and this made the variac failed?
  • Was the cable bad and the heat made the variac failed (then the problem is still there).

So, while I'm in the lab today, I'll keep the HEPA running, but upon my taking off, I'll turn it off. We'll discuss what to do in the meeting tomorrow.

 

Entry  Mon Apr 5 22:26:01 2021, gautam, Update, LSC, PRMI 1f locking (no ETMs) recovered PRMI_Apr5sensMat_consolidated.pdf

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.

Entry  Mon Apr 5 08:25:59 2021, Anchal, Paco, Update, General, Restore MC from early quakes 

[Paco, Anchal]

Came in a little bit after 8 and found the MC unlocked and struggling to lock for the past 3 hours. Looking at the SUS overview, both MC1 and ITMX Watchdogs had tripped so we damped the suspensions and brought them back to a good state. The autolocker was still not able to catch lock, so we cleared the WFS filter history to remove large angular offsets in MC1 and after this the MC caught its lock again.

Looks like two EQs came in at around 4:45 AM (Pacific) suggested by a couple of spikes in the seismic rainbow, and this.

Entry  Sat Apr 3 00:42:40 2021, gautam, Update, LSC, PRFPMI locking with half input power PRFPMIlock_1301464998_1301465238.pdfCARMplant.pdf

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.

Entry  Fri Apr 2 01:26:41 2021, gautam, Update, Electronics, REFL55 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%. 

Entry  Wed Mar 31 00:40:32 2021, Koji, Update, Electronics, Electronics Packaging for assembly work P_20210330_233508.jpgP_20210330_233618.jpg

I've worked on packing the components for the following chassis
- 5 16bit AI chassis
- 4 18bit AI chassis
- 7 16bit AA chassis
- 8 HAM-A coil driver chassis
They are "almost" ready for shipment. Almost means some small parts are missing. We can ship the boxes to the company while we wait for these small parts.

  • DB9 Female Ribbon Receptacle AFL09B-ND Qty100 (We have 10) -> Received 90 on Apr 1st
  • DB9 Male Ribbon Receptacle CMM09-G Qty100 (We have 10) -> Received 88 on Apr 1st
  • 4-40 Pan Flat Head Screw (round head, Phillips) 1/2" long Qty 50 -> Found 4-40 3/8" Qty50 @WB EE on Apr 1st (Digikey H782-ND)
  • Keystone Chassis Handle 9106 36-9106-ND Qty 50 -> Received 110 on Apr 1st
  • Keystone Chassis Ferrule 9121 NKL PL 36-9121-ND Qty 100 -> Received 55 on Apr 1st
  • Chassis Screws 4-40 3/16" Qty 1100 -> Received 1100 on Apr 1st
  • Chassis Ear Screws 6-32 1/2" 91099A220 Qty 150 -> Received 400 of 3/8" on Apr 1st
  • Chassis Handle Screws 6-32 1/4" 91099A205 Qty 100 -> included in the above
  • Powerboard mounting screw 4-40 Pan Flat Head Screw (round head, Phillips) 1/4" long Qty 125 -> Received 100 on Apr 1st

And some more additional items to fill the emptying stock.

  • 18AWG wires (we have orange/blue/black 1000ft, I'm sending ~1000ft black/green/white)
  • Already consumed 80% of 100ft 9pin ribbon cable (=only 20ft left in the stock)
    Reply  Thu Apr 1 18:16:28 2021, Koji, Update, Electronics, Electronics Packaging for assembly work 

All small components are packed in the boxes. They are ready to ship.

 

Entry  Thu Apr 1 00:50:06 2021, gautam, Update, SUS, PRMdiag 

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.

Entry  Thu Feb 18 20:24:48 2021, Koji, Summary, Electronics, A bunch of electronics received IMG_0416.jpeg

Todd provided us a bunch of electronics. I went to Downs to pick them up this afternoon and checked the contents in the box. Basically, the boxes are pretty comprehensive to produce the following chassis

  • 8 HAM-A coil driver chassis
  • 7 16bit Anti-Aliasing chassis
  • 4 18bit Anti-Imaging chassis
  • 5 16bit Anti-Imaging chassis

Some panels are missing (we cannibalized them for the WFS electronics). Otherwise, it seems that we will be able to assemble these chassis listed.
They have placed inside the lab as seen in the attached photo.


HAM-A COIL DRIVER (Req Qty 28+8)

- 8 Chassis
- 8 Front Panels
- 8 Rear Panels
- 8 HAM-A Driver PCBs
- 8 D1000217 DC Power board
- 8 D1000217 DC Power board

16bit AA (Req Qty 7)
- 7 CHASSIS
- 6 7 Front Panels (1 missing -> [Ed 2/22/2021] Asked Chub to order -> Received on 3/5/2021)
- 7 Rear Panels
- 28 AA/AI board S2001472-486, 499-511
- 7 D070100 ADC AA I/F
- 7 D1000217 DC Power board

18bit AI (Req Qty 4)
- 4 CHASSIS
- 4 Front Panels
- 4 Rear Panels
- 8 AA/AI board S2001463-67, 90-92
- 4 D1000551 18bit DAC AI I/F
- 4 D1000217 DC Power board
- bunch of excess components

16bit AI (Req Qty 5)
- 5 CHASSIS
- 4 5 Front Panels (D1101522) (1 missing -> [Ed 2/22/2021] Asked Chub to order -> Received on 3/5/2021)
- 3 5 Rear Panels (D0902784) (2 missing -> [Ed 2/22/2021] Asked Chub to order -> Received on 3/5/2021)
- 10 AA/AI board S2001468-71, 93-98
- 5 D1000217 DC Power board
- 5 D070101 DAC AI I/F

Internal Wiring Kit

[Ed 2/22/2021]
Asked Chub to order:
- Qty 12 1U Hamilton Chassis
- Qty 5 x Front/Rear Panels/Internal PCBs for D1002593 BIO I/F (The parts and connectors to be ordered separately)

  -> Front/Rear Panels received (3/5/2021)
  -> PCBs (unpopulated) received (3/5/2021)
  -> Components ordered by KA (3/7/2021)

    Reply  Sat Feb 20 10:01:48 2021, gautam, Summary, Electronics, A bunch of electronics received 

Will we also be receiving the additional 34 Satellite Amplifier PCBs?

       Reply  Sat Feb 20 16:46:17 2021, Koji, Summary, Electronics, A bunch of electronics received 

We received currently available sets. We are supposed to receive more coil drivers and sat amps, etc. But they are not ready yet.

 

    Reply  Fri Mar 5 00:53:09 2021, Koji, Summary, Electronics, A bunch of electronics received 

Received additional front/rear panels. Updated the original entry and Wiki [Link]

 

       Reply  Fri Mar 5 15:03:28 2021, gautam, Summary, Electronics, A bunch of electronics received 

The PCBs for the D1002593 BIO I/F (5pcs ea of D1001050 and D1001266) were received (from JLCPCB) today. idk what the status of the parts (digikey?) is.

Quote:

Received additional front/rear panels. Updated the original entry and Wiki [Link]

          Reply  Fri Mar 5 15:32:53 2021, Koji, Summary, Electronics, A bunch of electronics received 

The parts will be ordered by Koji The components for the additional BIO I/F have been ordered.

    Reply  Wed Mar 31 03:56:37 2021, Koji, Summary, Electronics, A bunch of electronics received P_20210331_013257.jpgP_20210331_014020.jpg

We have received 9x 18bit DAC adapter boards (D1000654)

Entry  Wed Mar 24 15:24:13 2021, gautam, Update, LSC, Notes on tests 

For my note-taking:

  1. Lock PRMI with ITMs as the MICH actuator. Confirm that the MICH-->PRCL contribution cannot be nulled. ✅  [15960]
  2. Lock PRMI on REFL165 I/Q. Check if transition can be made smoothly to (and from?) REFL55 I/Q.
  3. Lock PRMI. Turn sensing lines on. Change alignment of PRM / BS and see if we can change the orthogonality of the sensing.
  4. Lock PRMI. Put a razor blade in front of an out-of-loop photodiode, e.g. REFL11 or REFL33. Try a few different masks (vertical half / horizontal half and L/R permutations) and see if the orthogonality (or lack thereof) is mask-dependent.
  5. Double check the resistance/inductance of the PRM OSEMs by measuring at 1X4 instead of flange. ✅  [15966]
  6. Check MC spot centering.

If I missed any of the tests we discussed, please add them here.

    Reply  Wed Mar 24 22:54:49 2021, gautam, Update, LSC, New day, new problems PRMI3f_noArmssensMat.pdfREFL55_whtGainStepping.pngREFL55_whtGainStepping2.png

I thought I'd get started on some of the tests tonight. But I found that this problem had resurfaced. I don't know what's so special about the REFL55 photodiode - as far as I can tell, other photodiodes at the REFL port are running with comparable light incident on it, similar flat whitening gain, etc etc. The whitening electronics are known to be horrible because they use the quad LT1125 - but why is only this channel problematic? To describe the problem in detail:

  • I had checked the entire chain by putting an AM field on the REFL 55 photodiode, and corroborating the pk-to-pk (counts) value measured in CDS with the "nominal" setting of +18dB flat whitening gain against the voltage measured by a "reference" PD, in this case a fiber coupled NF1611.
  • In the above test, I confirmed that the measured signal was consistent with the value reported by the NF1611.
  • So, at least on Friday, the entire chain worked just fine. The PRMI PDH fringes were ~6000cts-pp in this condition.
  • Today, I found that while trying to acquire PRMI lock, the PDH fringes witnessed in REFL55 were saturating the ADC. I lowered the whitening gain to 0 dB (so a factor of 8). Then the PDH fringes were ~20,000cts-pp. So, overall, the gain of the chain seems to have gone up by a factor of ~25. 
  • Given my NF1611 based test, the part of the chain I am most suspicious of is the whitening filter. But I don't have a good mechanism that explains this observation. Can't be as simple as the input impedance of the LT1125 being lowered due to internal saturations, because that would have the opposite effect, we would measure a tiny signal instead of a huge one

I request Koji to look into this, time permitting, tomorrow. In slightly longer term, we cannot run the IFO like this - the frequency of occurrence is much too high and the "fix" seems random to me, why should sweeping the whitening gain fix the problem? There was some suggestion of cutting the PCB trace and putting a resistor to limit the current draw on the preceeding stage, but this PCB is ancient and I believe some traces are buried in internal layers. At the same time, I am guessing it's too much work to completely replace the whitening electronics with the aLIGO style units. Anyone have any bright ideas?


Anyway, I managed to lock the PRMI (ETMs misaligned) using REFL165I/Q. Then, instead of using the BS as the MICH actuator, I used the two ITMs (equal magnitude, opposite sign in the LSC output matrix).

  • The digital demod phase in this config is different from what is used when the arm cavities are in play (under ALS control). Probably the difference is telling us something about the reflectivity of the arm cavity for various sideband fields, from which we can extract some useful info about the arm cavity (length, losses etc). But that's not the focus here - the correct digital demod phase was 11 degrees. See Attachment #1 for the sensing matrix. I've annotated it with some remarks.
  • The signals appear much more orthogonal when actuating on the ITMs. However, I was still only able to null the MICH line sensed in the PRCL sensor to a ratio of 1/5 (while looking at peaks on DTT). I was unable to do better by fine tuning either the digital demod phase, or the relative actuation strength on each ITM
  • The PRCL loop had a UGF of ~120 Hz, MICH loop ~60 Hz.
  • With the PRMI locked in this config, I tried to measure the appropriate loop gain and sign if I were to use the REFL55 photodiode instead of REFL165 - but I didn't have any luck. Unsurprising given the known electronics issues I guess...

I didn't get around to running any of the other tests tonight, will continue tomorrow.


Update Mar 26: Attachments #2 and #3 show that there is clearly something wrong with the whitening electronics associated with REFL55 channels - with the PSL shutter closed (so the only "signal" being digitized should be the electronics noise at the input of the whitening stage), the I and Q channels don't show similar profiles, and moreover, are not consistent (the two screenshots are from two separate sweeps). I don't know what to make of the parts of the sweep that don't show the expected "steps". Until ndscope gets a log-scaled y-axis option, we have to live with the poor visualization of the gain steps which are dB (rather than linearly) spaced. For this particular case, StripTool isn't an option either because the Q channel as a negative offset, and I opted agains futzing with the cabling at 1Y2 to give a small fixed positive voltage instead. I will emphasize that on Friday, this problem was not present, because the gain balance of the I and Q channels was good to within 1dB.

       Reply  Mon Mar 29 19:32:46 2021, gautam, Update, LSC, REFL55 whitening checkout REFL55wht.png

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.

Entry  Thu Mar 25 18:05:04 2021, gautam, Update, Electronics, Stuffed 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.

Entry  Thu Mar 25 17:39:28 2021, gautam, Update, Computer Scripts / Programs, Spot position measurement scripts "modernized" MCdecenter202103251735_mcmirror0.pdfMCdecenter202103251735_mcdecenter0.pdf

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.

Entry  Fri Mar 12 03:08:23 2021, Koji, Summary, SUS, Coil Rs & Ls for PRM/BS/SRM P_20210311_224651.jpgP_20210311_225359.jpg

Summary

Per Gautam's request, I've checked the coil resistances and inductances.

  • PRM/BS/SRM coils were tested.
  • All the PRM coils look well-matched in terms of the inductance. Also, I didn't find a significant difference from BS coils.
  • Pin 1 of the feedthru connectors is shorted to the vacuum chamber.
  • A discovery was that: The SRM DSUB pinouts are mirrored compared to the other suspensions.

Method

A DSUB25 breakout was directly connected to the flange (Attachment 1).
The impedance meter was nulled every time the measurement range and type (R or L) were changed.

Result

Feedthru connector: PRM1
Pin1 - flange: R = 0.8Ω
Pin11-23 / R = 1.79Ω / L=3.21mH
Pin 7-19 / R = 1.82Ω / L=3.22mH
Pin 3-15 / R = 1.71Ω / L=3.20mH

Feedthru connector: BS1
Pin1 - flange: R = 0.5Ω
Pin11-23 / R = 1.78Ω / L=3.26mH
Pin 7-19 / R = 1.63Ω / L=3.30mH
Pin 3-15 / R = 1.61Ω / L=3.29mH

Feedthru connector: SRM1
Pin1 - flange: R = 0.5Ω

Pin11-24 / R = 18.1Ω / L=3.22mH
Pin 7-20 / R = 18.8Ω / L=3.25mH
Pin 3-16 / R = 20.3Ω / L=3.25mH

Feedthru connector: PRM2
Pin1 - flange: R = 0.6Ω
Pin11-23 / R = 1.82Ω / L=3.20mH
Pin 7-19 / R = 1.53Ω / L=3.20mH
Pin 3-15 / R = N/A

Feedthru connector: BS2
Pin1 - flange: R = 0.6Ω
Pin11-23 / R = 1.46Ω / L=3.27mH
Pin 7-19 / R = 1.54Ω / L=3.24mH
Pin 3-15 / R = N/A

Feedthru connector: SRM2
Pin1 - flange: R = 0.7Ω
Pin11-24 / R = N/A

Pin 7-20 / R = 18.5Ω / L=3.21mH
Pin 3-16 / R = 19.1Ω / L=3.25mH

Observation

The SRM pinouts seem mirrored compared to the others. In fact, these two connectors are equipped with mirror cables (although they are unshielded ribbons) (Attachment 2).

The SRM sus is located on the ITMY table. There is a long in vacuum DSUB25 cable between the ITMY and BS tables. I suspect that the cable mirrors the pinout and this needs to be corrected by the in-air mirror cables.

I went around the lab and did not find any other suspensions which have the mirror cable.

WIth the BHD configuration, we will move the feedthru for the SRM to the one on the ITMY chamber. So I believe the situation is going to be improved.

 

    Reply  Fri Mar 12 12:32:54 2021, gautam, Summary, SUS, Coil Rs & Ls for PRM/BS/SRM BS_actuator.pdfPRMact.pdf

For consistency, today, I measured both the BS and PRM actuator balancing using the same technique and don't find as serious an imbalance for the BS as in the PRM case. The Oplev laser source is common for both BS and PRM, but the QPDs are of course distinct.

BTW, I thought the expected resistance of the coil windings of the OSEM is ~13 ohms, while the BS/PRM OSEMs report ~1-2 ohms. Is this okay?

Quote:
 
  • All the PRM coils look well-matched in terms of the inductance. Also, I didn't find a significant difference from BS coils.
       Reply  Fri Mar 12 13:01:43 2021, rana, Summary, SUS, Coil Rs & Ls for PRM/BS/SRM 

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

          Reply  Fri Mar 12 13:48:53 2021, gautam, Summary, SUS, Coil Rs & Ls for PRM/BS/SRM 

I didn't repeat Koji's measurement, but he reports the expected ~3.2mH per coil on all the BS and PRM coils.

Quote:

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

    Reply  Thu Mar 25 16:02:15 2021, gautam, Summary, SUS, Repeated 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.
Entry  Tue Mar 16 14:37:36 2021, Yehonathan, Update, BHD, SOS SmCo magnets Inspection 20210316_142906.jpg20210316_165626.jpg20210316_165838.jpg

In the cleanroom, I opened the nickel-plated SmCo magnet box to take a closer look. I handled the magnets with tweezers. I wrapped the tips of the tweezers with some Kapton tape to prevent scratching and magnetization.

I put some magnets on a razor blade and took some close-up pictures of the face of the magnets on both sides. Most of them look like attachment 1.

Some have worn off plating on the edges. The most serious case is shown in attachment 2. Maybe it doesn't matter if we are going to sand them?

I measure the magnetic flux of the magnets by just attaching the gaussmeter flat head to the face of the magnet and move it around until the maximum value is reached.

For envelope #1 out of 3 the values are: (The magnet ordering is in attachment 3):

Magnet # Max Magnetic Field (kG)
1 2.57
2 2.54
3 2.57
4 2.57
5 2.55
6 2.61
7 2.55
8 2.52
9 2.64
10

2.58

Going to continue tomorrow with the rest of the magnets. I left the magnet box and the gaussmeter under the flow bench in the cleanroom.

    Reply  Wed Mar 17 14:40:39 2021, Yehonathan, Update, BHD, SOS SmCo magnets Inspection 

Continuing with envelope number 2

Magnet number Magnetic field (kG)
1 2.89
2 2.85
3 2.92
4 2.75
5 2.95
6 2.91
7 2.93
8 2.9
9 2.93
10 2.9
11 2.85
12 2.89
13 2.85
14 2.88
15 2.92
16 2.75
17 2.97
18 2.88
19 2.85
20 2.87
21 2.93
22 2.9
23 2.9
24 2.89
25 2.88
26 2.88
27 2.95
28 2.88
29 2.88
30 2.9
31 2.96
32 2.91
33 2.93
34 2.9
35 2.9
36 3.03
37 2.84
38 2.95
39 2.89
40 2.88
41 2.88
42 2.93
43 2.97
44 2.74
45 2.84
46 2.85
47 2.85
48 2.87
49 2.88
50 2.8

I think I have to redo envelope 1 tomorrow.

    Reply  Thu Mar 25 14:58:16 2021, Yehonathan, Update, BHD, SOS SmCo magnets Inspection 

Redoing magnet measurement of envelope 1:

Magnet # Max Magnetic Field (kG)
1

2.89

2 2.82
3 2.86
4 2.9
5 2.86
6 2.73
7 2.9
8 2.88
9 2.85
10 2.93

Moving on to inspect and measure envelope 3 (the last one):

Magnet # Max Magnetic Field (kG)
1 2.92
2 2.85
3 2.93
4 2.97
5 2.9
6 3.04
7 2.9
8 2.92
9 3
10 2.92
11 2.94
12 2.92
13 2.92
14 2.95
15 3.02
16 2.91
17 2.89
18 2.9
19 2.86
20 2.9
21 2.92
22 2.9
23 2.87
24 2.93
25 2.85
26 2.88
27 2.92
28 2.9
29 2.9
30 2.89
31 2.83
32 2.83
33 2.8
34 2.94
35 2.88
36 2.91
37 2.9
38 2.91
39 2.94
40 2.88

 

Entry  Mon Mar 22 16:29:17 2021, gautam, Update, ASC, Some prep for AS WFS commissioning AS_WFS_head.pngWFSquads.pdf
  1. Added rough cts2mW calibration filters to the quadrants, see Attachment #1. The number I used is:
              0.85 A/W         *       500 V/A            *          10 V/V                              *         1638.4 cts/V
    (InGaAs responsivity)     (RF transimpedance)  (IQ demod conversion gain)      (ADC calibration)
  2. Recovered FPMI locking. Once the arms are locked on POX / POY, I lock MICH using AS55_Q as a sensor and BS as an actuator with ~80 Hz UGF.
  3. Phased the digital demod phases such that while driving a sine wave in ETMX PIT, I saw it show up only in the "I" quadrant signals, see Attachment #2.

The idea is to use the FPMI config, which is more easily accessed than the PRFPMI, to set up some tests, measure some TFs etc, before trying to commission the more complicated optomechanical system.

Entry  Sun Mar 21 19:31:29 2021, rana, Summary, Electronics, RTL-SDR for monitoring RF noise / interference Screen_Shot_2021-03-21_at_7.43.24_PM.png

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.

ELOG V3.1.3-