40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 318 of 329  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  15747   Sun Jan 3 16:26:06 2021 KojiUpdateSUSIMC WFS check (Yet another round of Sat. Box. switcharoo)

I wanted to check the functionality of the IMC WFS. I just turned on the WFS servo loops as they were. For the past two hours, they didn't run away. The servo has been left turned on. I don't think there is no reason to keep it turned off.

Attachment 1: Screen_Shot_2021-01-03_at_17.14.57.png
Screen_Shot_2021-01-03_at_17.14.57.png
  15748   Wed Jan 6 15:28:04 2021 gautamUpdateVACVac rack UPS batteries replaced

[chub, gautam]

the replacement was done this afternoon. The red "Replace Battery" indicator is no longer on.

  15749   Wed Jan 6 16:18:38 2021 gautamUpdateOptical LeversBS Oplev glitchy

As part of the hunt why the X arm IR transmission RIN is anomalously high, I noticed that the BS Oplev Servo periodically kicks the optic around - the summary pages are the best illustration of this happening. Looking back in time, these seem to have started ~Nov 23 2020. The HeNe power output has been degrading, see Attachment #1, but this is not yet at the point where the head usually needs replacing. The RIN spectrum doesn't look anomalous to me, see Attachment #2 (the whitening situation for the quadrants is different for the BS and the TMs, which explains the HF noise). I also measured the loop UGFs (using swept sine) - seems funky, I can't get the same coherence now (live traces) between 10-30 Hz that I could before (reference traces) with the same drive amplitude, and the TF that I do measure has a weird flattening out at higher frequencies that I can't explain, see Attachment #3.

The excess RIN is almost exactly in the band that we expect our Oplevs to stabilize the angular motion of the optics in, so maybe needs more investigation - I will upload the loop suppression of the error point later. So far, I don't see any clean evidence of the BS Oplev HeNe being the culprit, so I'm a bit hesitant to just swap out the head...

Attachment 1: missingData.png
missingData.png
Attachment 2: OLRIN.pdf
OLRIN.pdf
Attachment 3: BS_OL_P.pdf
BS_OL_P.pdf
Attachment 4: BS_OL_suppression.pdf
BS_OL_suppression.pdf
  15750   Wed Jan 6 19:00:04 2021 gautamUpdateLSCPhase loss in POX/POY loops

I've noticed that there is some phase loss in the POX/POY locking loops - see Attachment #1, live traces are from a recent measurement while the references are from Nov 4 2018. Hard to imagine a true delay being responsible to cause so much phase loss at 100 Hz. Attachment #2 shows my best effort loop modeling, I think I've got all the pieces, but maybe I missed something (I assume the analog whitening / digital anti-whitening are perfectly balanced, anyway this wasn't messed with anytime recently)? The fitter wants to add 560 us (!) of delay, which is almost 10 clock cycles on the RTS, and even so, the fit is poor (I constrain the fitter to a maximum of 600 us delay so maybe this isn't the best diagnostic). Anyway, how can this change be explained? The recent works I can think of that could have affected the LSC sensing were (i) RF source box re-working, and (ii) vent. But I can't imagine how either of these would introduce phase loss in the LSC sensing. Note that the digital demod phase has been tuned to put all the PDH signal in the "I" quadrature, which is the condition in which the measurement was taken.

Probably this isn't gonna affect locking efforts (unless it's symptomatic of some other larger problem).

Attachment 1: POXloop.pdf
POXloop.pdf
Attachment 2: loopFit.pdf
loopFit.pdf
  15751   Wed Jan 6 22:47:41 2021 gautamUpdateALSNoisy ALS

Summary:

I want to get back to locking the interferometer so I can test out the newly installed AS WFS. However, the ALS noise is far too high, at least the transition of arm length control from IR to ALS fails reliably with the same settings that worked so reliably previously. I worked on investigating it a bit today.

Timeline

In the latter half of last year, I was focused on the air-BHD setup, so I wasn't checking in on the ALS noise as regularly. 

  1. On Aug 17, the noise was fine.
  2. But on Oct 29, the noise is bad (and it continues to remain so, to the point where I cannot lock the interferometer). 
  3. Koji and Anchal confirmed nothing was touched while they were investigating the ALS system, also on Oct 29. The spectra attached in #15650 don't make any sense to me, the noise at 100 Hz cannot be <100mHz/rtHz. So, inconclusive.

Excess noise:

All tests are done with the arm cavity length locked to the PSL frequency using POX. Then, the EX laser is locked to the arm cavity length using the AUX PDH servo. The fluctuations in the beatnote between the two lasers is what is monitored as a diagnostic. See Attachment #1. The reference traces in the top pane are from a known good time. The large excess noise between ~80-200 Hz is what I'm concerned about.

A separate issue that can improve the noise is to track down the noise in the 20-80 Hz band - probably some IMC frequency noise issue.

Noise budget:

See Attachment #2

  • I am pretty confident the electronics after the beat mouth are not to blame - I injected a 50 MHz signal from a Marconi and adjusted the signal amplitude to mimic what we get from the beat mouth. The trace labelled "DFD electronics noise" is the noise in this config.
  • The unsuppressed AUX frequency noise was measured with an SR785 (converted to freqnecy noise units knowing the PDH horn-to-horn voltage and the cavity linewidth). I didn't confirm the sensing noise level (dark noise of the AUX PDH loop), but I figure that at 100 Hz (voltage noise of ~100 uV/rtHz on the SR785), we are above the sensing noise level, and so are truly measuring the in-loop frequency noise of the stabilized AUX laser. I also confirmed that the loop UGF was ~10 kHz and phase margin was ~60 degrees, which are nominal numbers.
  • The fact that the excess noise is only in the X arm channel means the PSL frequency is not to blame.

So what could it be? The only things I can think of are (i) the beat mouth photodiode (NF1611) or (ii) excess noise in the fiber carrying the light from EX to the PSL table (but only on this fiber, and not on the EY fiber). Both seem remote to me - I'll test the former by switching the EX and EY fiber inputs to the beat mouth, but apart from this, I'm out of ideas... 

To avoid this kind of issue, we should really have scripted locks of all the basic IFO configs and record the data to summary pages or something - maybe something to do once Guardian is installed, it'd be pretty hacky to do cleanly with shell scripts.

Attachment 1: ALSX_excess.png
ALSX_excess.png
Attachment 2: budget.pdf
budget.pdf
  15752   Thu Jan 7 19:16:11 2021 gautamUpdateALSNoisy ALS

I'm also wondering why the error monitors for the X and Y loops report such wildly different spectra for the suppressed frequency noise of the AUX laser relative to the cavity length, see Attachment #1. The y-axis should be approximately Hz/rtHz. In both cases, the servo's error point monitor is connected to the DAQ system via a G=10 SR560. With the SR785, I measure for EX a nice bucket-shaped spectrum, bottoming out at ~10 uV/rtHz around 40 Hz, see Attachment #2. The SR560 should have an input-referred noise much less than this at the G=10 setting. The ADC noise level is only ~5 uV/rtHz, and indeed, the EY spectrum shows the expected shape. So what's up with the EX error mon? Tried swapping out the SR560 for a different unit, no change. And both the SR560 noise, and the ADC noise, check out when everything is checked individually. So some kind of interaction once everything is connected together, but it's only present at EX...

Today, I tried switching the EX and EY fibers going into the beat mouth, but I preserved the channel mapping after the beat mouth by switching the electrical outputs as well (the goal was to make sure that the beat photodiodes weren't the issue here, I think the electronics are already exonerated since driving the channel with a Marconi doesn't produce these noisy features). The EX spectrum remains noisy. I've switched everything back to the nominal configuration now to avoid further confusion. So it would appeat that this is real frequency noise that gets added in the EX fiber somehow. What can I do to fix this? The source of coupling isn't at the PSL table, else the EY channel would also show similar features. Visually, nothing seems wrong to me at EX either. So the problem is somehow in the cable tray along which the 40m of fiber is routed? This is already inside some nice foam/tubing setup, what can be done to improve it? Still doesn't explain why it suddenly became noisy...

Attachment 1: ALS_ERR_MON.pdf
ALS_ERR_MON.pdf
Attachment 2: AUXnoise.pdf
AUXnoise.pdf
  15753   Thu Jan 7 20:07:27 2021 KojiUpdateALSNoisy ALS

How about resurrecting the PSL table green beat for the X arm to see if the non-fiber setup shows the same level of the freq noise (e.g. the PDH locking became super noisy due to misalignment etc).

  15754   Thu Jan 7 21:16:22 2021 gautamUpdateALSNoisy ALS

I thought about it, but wouldn't that show up at the AUX PDH error point? Or because the loop gain is so high there we wouldn't see a small excess? I suppose there could be some clipping on the Faraday or something like that. But the GTRX level and the green REFL DC level when locked are nominal.

Quote:

How about resurrecting the PSL table green beat for the X arm to see if the non-fiber setup shows the same level of the freq noise (e.g. the PDH locking became super noisy due to misalignment etc).

  15755   Thu Jan 7 23:25:19 2021 KojiUpdateALSNoisy ALS

If the sensing noise level of the end PDH degraded for some reason, it'd make the out of loop stability worse without making the end pdh error level degraded.
It's just speculation.

 

  15756   Fri Jan 8 20:01:11 2021 gautamUpdateALSNoisy ALS

I did this test today. The excess noise around 100 Hz doesn't show up in the green beat.

See Attachment #1. The setup was as usual:

  • X-Arm cavity length stabilized to PSL frequency using the POX locking loop.
  • EX laser frequency locked to the X-Arm cavity length using the AUX PDH loop.
  • The "BEATX" channel records frequency fluctuations in the beat sensed on the IR beat photodiode, while the "BEATY" channel records frequency fluctuations in the beat sensed on the Green beat photodiode.
  • Since the green beat frequency fluctuations are twice that of the IR beat frequency fluctuations, I scaled the former ASD by a factor of 0.5 so as to compare apples to apples.
  • At low frequencies, the green beat is noisier, but that channel doesn't show the excess noise at mid frequencies you see in the IR beat. So the AUX PDH sensing noise is not to blame I think.

So, this excess appears to truly be excess phase noise on the fiber (though I have no idea what the actual mechanicsm could be or what changed between Aug and Oct 2020 that could explain it. Maybe the HEPA?

For this work, I had to spend some time aligning the two green beams onto the beat photodiode. During this time, I shuttered the PSL, disabled feedback via the FSS servo, turned the HEPA high, and kept the EX green locked to the arm so as to have a somewhat stable beat signal I could maximize. Everything has been returned to nominal settings now (obviously, since I locked the arms to get the data).


You may ask, why do we care. In terms of RMS frequency noise, it would appear that this excess shouldn't matter. But in all my trials so far, I've been unable to transition control of the arm cavity lengths from POX/POY to ALS. I suppose we could try using the green beat, but that has excess low frequency noise (which was the whole point of the fiber coupled setup). 

Quote:

How about resurrecting the PSL table green beat for the X arm to see if the non-fiber setup shows the same level of the freq noise (e.g. the PDH locking became super noisy due to misalignment etc).

Attachment 1: ALSX_IR_green.pdf
ALSX_IR_green.pdf
  15758   Mon Jan 11 16:11:51 2021 YehonathanUpdateBHDMonte Carlo loop coupling Simulations

I dived into the alog to make the OLTFs in the MC_controls example more realistic. I was mainly inspired by these entries:

https://alog.ligo-la.caltech.edu/aLOG/uploads/47116_20190708131007_carmolg_20190702.png

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=18742

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20466

and Evan's and Dennis's Theses.

Attachment 1 shows the new OLTFs. I tried to make them go like 1/f around the UGF and fall as quickly as possible at higher frequencies. I didn't do more advanced stability checks.

I also noticed that imbalances and detunings in the MC simulation can change the plants significantly. Especially DARM, CARM, and sometimes PRCL. I added the option to fix some OLTFs throughout the simulation. At every iteration, the simulation computes the required control filter to fix the selected OLTFs such that it will match the OLTFs in the undetuned and balanced IFO.

 

 

 

Attachment 1: MC_LANCE_OLTFs.pdf
MC_LANCE_OLTFs.pdf
  15759   Mon Jan 11 19:10:10 2021 ranaUpdateBHDMonte Carlo loop coupling Simulations
  • looking better, but the CARM plot still looks weird.
  • you should plot from 0.01 - 10,000 Hz
  • All of the loops should have true integrators below 1 Hz.
  • I don't think these loops are stable; the Bode plot is not a good way to check stability for LTI systems since you can be fooled by phase wrapping.
  15763   Thu Jan 14 11:46:20 2021 gautamUpdateCDSExpansion chassis from LHO

I picked the boxes up this morning. The inventory per Fil's email looks accurate. Some comments:

  1. They shipped the chassis and mounting parts (we should still get rails to mount these on, they're pretty heavy to just be supported on 4 rack nuts on the front). idk if we still need the two empty chassis that were requested from Rich.
  2. Regarding the fibers - one of the fibers is pre-2012. These are known to fail (according to Rolf). One of the two that LHO shipped is from 2012 (judging by S/N, I can't find an online lookup for the serial number), the other is 2011. IIRC, Rolf offered us some fibers so we may want to take him up on that. We may also be able to use copper cables if the distances b/w server and expansion chassis are short.
  3. The units are fitted with a +24V DC input power connector and not the AC power supplies that we have on all the rest of the chassis. This is probably just gonna be a matter of convenience, whether we want to stick to this scheme or revert to the AC input adaptor we have on all the other units. idk what the current draw will be from the Sorensen - I tested that the boards get power, and with noi ADCs/DACs/BIOs, the chassis draws ~1A (read off from DCPS display, not measured with a DMM). ~Half of this is for the cooling fans It seems like KT @ LLO has offered to ship AC power supplies so maybe we want to take them up on that offer.
  4. Without the host side OSSI PCIe card, timing interface board, and supermicro servers that actually have enough PCIe slots, we still can't actually run any meaningful test. I ran just a basic diagnostic that the chassis can be powered on, and the indicator LEDs and cooling fans run.
  5. Some photos of the contents are here. The units are stored along the east arm pending installation.

    >     Koji,
    >
    >     Barebones on this order.
    >
    >        1. Main PCIe board
    >        2. Backplane (Interface board)
    >        3. Power Board
    >        4. Fiber (One Stop) Interface Card, chassis side only
    >        5. Two One Stop Fibers
    >        6. No Timing Interface
    >        7. No Binary Cards.
    >        8. No ADC or DAC cards
    >
    >     Fil Clara
    >       
  15764   Thu Jan 14 12:19:43 2021 JonUpdateCDSExpansion chassis from LHO

That's fine, we didn't actually request those. We bought and already have in hand new PCIe x4 cables for the chassis-host connection. They're 3 m copper cables, which was based on the assumption of the time that host and chassis would be installed in the same rack.

Quote:
  1. Regarding the fibers - one of the fibers is pre-2012. These are known to fail (according to Rolf). One of the two that LHO shipped is from 2012 (judging by S/N, I can't find an online lookup for the serial number), the other is 2011. IIRC, Rolf offered us some fibers so we may want to take him up on that. We may also be able to use copper cables if the distances b/w server and expansion chassis are short.
  15765   Thu Jan 14 12:32:28 2021 gautamUpdateCDSRogue master may be doing something good?

I think the "Rogue Master" setting on the RFM network may be doing some good. 5 mins, ago, all the CDS indicators were green, but I noticed an amber light on the c1rfm screen just now (amber = warning). Seems like at GPS time 1294691182, there was some kind of error on the RFM network. But the network hasn't gone down. I can clear the amber flag by running the global diag reset. Nevertheless, the upgrade of all RT systems to Dolphin should not be de-prioritized I think.

Attachment 1: Screenshot_2021-01-14_12-35-52.png
Screenshot_2021-01-14_12-35-52.png
  15766   Fri Jan 15 15:06:42 2021 JonUpdateCDSExpansion chassis from LHO

Koji asked me assemble a detailed breakdown of the parts received from LHO, which I do based on the high-res photos that Gautam posted of the shipment.

Parts in hand:

Qty Part Note(s)
2 Chassis body  
2 Power board and cooling fans As noted in 15763, these have the standard LIGO +24V input connector which we may want to change
2 IO interface backplane  
2 PCIe backplane  
2 Chassis-side OSS PCIe x4 card  
2 CX4 fiber cables These were not requested and are not needed

Parts still needed:

Qty Part Note(s)
2 Host-side OSS PCIe x4 card These were requested but missing from the LHO shipment 
2 Timing slave These were not originally requested, but we have recently learned they will be replaced at LHO soon

Issue with PCIe slots in new FEs

Also, I looked into the mix-up regarding the number of PCIe slots in the new Supermicro servers. The motherboard actually has six PCIe slots and is on the CDS list of boards known to be compatible. The mistake (mine) was in selecting a low-profile (1U) chassis that only exposes one of these slots. But at least it's not a fundamental limitation.

One option is to install an external PCIe expansion chassis that would be rack-mounted right above the FE. It is automatically configured by the system BIOS, so doesn't require any special drivers. It also supports hot-swapping of PCIe cards. There are also cheap ribbon-cable riser cards that would allow more cards to be connected for testing, although this is not as great for permanent mounting.

It may still be better to use the machines offered by Keith Thorne from LLO, as they're more powerful anyway. But if there is going to be an extended delay before those can be received, we should be able to use the machines we already have in conjunction with one of these PCIe expansion options.

  15767   Fri Jan 15 16:54:57 2021 gautamUpdateCDSExpansion chassis from LHO

Can you please provide a link to this "list of boards"? The only document I can find is T1800302. In that, under "Basic Requirements" (before considering specific motherboards), it is specified that the processor should be clocked @ >3GHz. The 3 new supermicros we have are clocked at 1.7 GHz. X10SRi-F boards are used according to that doc, but the processor is clocked at 3.6 or 3.2 GHz.

Please also confirm that there are no conflicts w.r.t. the generation of PCIe slots, and the interfaces (Dolphin, OSSI) we are planning to use - the new machines we have are "PCIe 2.0" (though i have no idea if this is the same as Gen 2). 

Quote:

The motherboard actually has six PCIe slots and is on the CDS list of boards known to be compatible.

As for the CX4 cable - I still think it's good to have these on hand. Not good to be in a situation later where FE and expansion chassis have to be in different racks, and the copper cable can't be used.

Attachment 1: Screenshot_2021-01-15_17-00-06.png
Screenshot_2021-01-15_17-00-06.png
  15768   Fri Jan 15 17:04:45 2021 gautamUpdateLSCMessed up LSC sensing

I want to lock the PRFPMI again (to commission AS WFS). Have had some success - but in doing characterization, I find that the REFL port sensing is completely messed up compared to what I had before. Specifically, MICH and PRCL DoFs have no separation in either the 1f or 3f photodiodes. 

  • A sensing line driven in PRCL doesn't show up in the AS55 photodiode signal - this is good and as expected.
  • For MICH - I set the MICH--->PRM actuation matrix element so as to minimize the height of the peak at the MICH drive frequency that shows up at the PRCL error point. My memory is that I used to be able to pretty much null this signal in the past, but I can't find a DTT spectrum in the elog as evidence. Anyways, the best effort nulling I can achieve now still results in a large peak at the PRCL error point. Since the sensing matrix doesn't actually make any sense, idk if it is meaningful to even try and calibrate the above qualitative statement into quantitative numbers of cross coupling in meters.
  • With the PRMI locked on 1f error signals (ETMs misaligned, PRCL sensed with REFL11_I, MICH sensed with AS55_Q) - I tried tweaking the digital demod phase of the REFL33 and REFL165 signals. But I find that the MICH and PRCL peaks move in unison as I tweak the demod phase. This suggests to me that both signals are arriving optically in phase at the photodiode, which is weird.
  • The phenomenon is seen also in the REFL11 signal.

I did make considerable changes to the RF source box, and so now the relative phase between the 11 MHz and 55 MHz signals is changed compared to what it was before. But do we really expect any effect even in the 1f signal? I am not able to reproduce this effect in simulation (Finesse), though I'm using a simplified model. I attach two sensing matrices to illustrate what i mean:

  1. Attachment #1 is in the PRFPMI state, with the IFO on RF control (CARM on REFL11, PRCL on REFL165_I, MICH on REFL165_Q, DARM on AS55_Q). 
  2. Attachment #2 is between the transition to RF control (CARM and DARM on ALS, PRCL on REFL165_I, MICH on REFL165_Q). The CARM offset is ~4nm (c.f. the linewidth of ~20pm), so the circulating power in the arm cavities is low.
Attachment 1: PRFPMI_Jan12sensMat.pdf
PRFPMI_Jan12sensMat.pdf
Attachment 2: PRMI3f_ALS_Jan11_largeOffsetsensMat.pdf
PRMI3f_ALS_Jan11_largeOffsetsensMat.pdf
  15769   Sat Jan 16 18:59:44 2021 gautamUpdateLSCModulation depth measurement

I decided to analyze the data I took in December more carefully to see if there are any clues about the weird LSC sensing.

Attachment #1 shows the measurement setup.

  • The PSL shutter was closed. All feedback to both lasers was disconnected during the measurement. I also disabled the input switch to the FSS Box - so the two laser beams being interfered shouldn't have any modulations on them other than the free running NPRO noise and the main IFO modulations.
  • Everything is done in fiber as I had the beams already coupled into collimators and this avoided having to optimize any mode matching on the beat photodiode.
  • The pickoff of the PSL is from the collimator placed after the triply resonant EOM that was installed for the air BHD experiment.
  • The other beam is the EX laser beam, arriving at the PSL table via the 40m long fiber from the end (this is the usual beam used for ALS).
  • I didn't characterize precisely the PLL loop shape. But basically, I wasn't able to increase the SR560 gain any more without breaking the PLL lock. Past experience suggests that the UGF is ~20 kHz, and I was able to get several averages on the AG4395 without the lock being disturbed.

Attachment #2 shows the measured spectrum with the PSL and EX laser frequency offset locked via PLL.

  • The various peaks are identified.
  • There are several peaks which I cannot explain - any hypothesis for what these might be? Some kind of Sorensen pollution? They aren't any multiples of any of the standard RF sources. They are also rather prominent (and stationary during the measurement time, which I think rules out the cause being some leakage light from the EY beam, which I had also left connected to the BeatMouth during the measurement).
  • In the previous such characterization done by Koji, such spurious extra peaks aren't seen.
  • Also, I can't really explain why some multiples of the main modulation are missing (could also be that my peak finding missed the tiny peaks)?
  • The measuremet setup is very similar to what he had - important differences are 
    • Much of the optical path was fiber coupled.
    • Beat photodiode is NF1611, which is higher BW than the PDA10CF.
    • The second laser source was the Innolight EX NPRO as opposed to the Lightwave that was used.
    • The RF source has been modified, so relative phasing between 11 MHz and 55 MHz is different.

Fitting the measured sideband powers (up to n=7, taking the average of the measured upper and lower sideband powers to compute a least squares fit if both are measured, else just that of the one sideband measured) agains those expected from a model, I get the following best fit parameters:

\begin{align*} \Gamma_1 &= 0.193 \pm 0.004 \\ \Gamma_2 &= 0.246 \pm 0.008 \\ \phi &= 75.5^{\circ +17.5^{\circ}}_{\, -40.3^{\circ}} \end{align*}

To be explicit, the residual at each datapoint was calculated as

\Delta = \bigg| \frac{\rm{model}-\rm{measurement}}{\rm{model}}\bigg|^2.

The numbers compare favourably with what Koji reported I think - the modulation depths are slightly increased, consistent with the RF power out of the RF box being slightly increased after I removed various attenuators etc. Note the large uncertainty on the relative phase between the two modulations - I think this is because there are relatively few sidebands (one example is n=3) which has a functional dependence that informs on phi - most of the others do not directly give us any information about this parameter (since we are just measuring powers, not the actual phase of the electric field). 

Attachment #3 shows a plot of the measured modulation profile, along with the expected heights plugging the best fit parameters into the model. The size of the datapoint markers is illustrative only - the dependence on the model parameters is complicated and the full covariance would need to be taken into account to put error bars on those markers, which I didn't do. 

Attachment #4 shows a time domain measurement of the relative phasing between the 11 MHz and 55 MHz signals at the EOM drive outputs on the RF source box. I fit a model there and get a value for the relative phase that is totally inconsistent from what I get with this fit. 

Attachment 1: PLL.pdf
PLL.pdf
Attachment 2: modDepth.pdf
modDepth.pdf
Attachment 3: modProfile.pdf
modProfile.pdf
Attachment 4: EOMpath_postMod.pdf
EOMpath_postMod.pdf
  15770   Tue Jan 19 13:19:24 2021 JonUpdateCDSExpansion chassis from LHO

Indeed T1800302 is the document I was alluding to, but I completely missed the statement about >3 GHz speed. There is an option for 3.4 GHz processors on the X10SRi-F board, but back in 2019 I chose against it because it would double the cost of the systems. At the time I thought I had saved us $5k. Hopefully we can get the LLO machines in the near term---but if not, I wonder if it's worth testing one of these to see whether the performance is tolerable.

Can you please provide a link to this "list of boards"? The only document I can find is T1800302....

I confirm that PCIe 2.0 motherboards are backwards compatible with PCIe 1.x cards, so there's no hardware issue. My main concern is whether the obsolete Dolphin drivers (requiring linux kernel <=3.x) will work on a new system, albeit one running Debian 8. The OSS PCIe card is automatically configured by the BIOS, so no external drivers are required for that one.

Please also confirm that there are no conflicts w.r.t. the generation of PCIe slots, and the interfaces (Dolphin, OSSI) we are planning to use - the new machines we have are "PCIe 2.0" (though i have no idea if this is the same as Gen 2). 

  15773   Wed Jan 20 10:13:06 2021 gautamUpdateElectronicsHV Power supply bypassing

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.

Attachment 1: bypassCaps.pdf
bypassCaps.pdf
Attachment 2: IMG_9079.jpg
IMG_9079.jpg
Attachment 3: IMG_9078.jpg
IMG_9078.jpg
Attachment 4: HVampNoise_driven_chassis.pdf
HVampNoise_driven_chassis.pdf
Attachment 5: printCoilCurrents.pdf
printCoilCurrents.pdf
  15775   Wed Jan 20 19:12:16 2021 gautamUpdateCDSSLwebview fixed

After fixing multiple issues, the model webviews are updating, should be done by tomorrow. It should be obvious from the timestamps on the index page which are the new ones. These new screens are better than the old ones and offer more info/details. Please look at them, and let me know if there are broken links etc. Once we are happy with this new webview, we can archive the old files and clean up the top directory a bit. I don't think this adds anything to the channel accounting effort but it's a nice thing to have up-to-date webviews, I found the LLO ones really useful in setting up the AS WFS model.

BTW, the crontab on megatron is set to run every day at 0844. The process of updating the models is pretty heavy because of whatever MATLAB overhead. Do we really need to have this run every day? I modified the crontab to run every other Saturday, and we can manually run the update when we modify a model. Considering this hasn't been working for ~3 years, I think this is fine, but if anyone has strong preference you can edit the crontab.

If someboy can volunteer to fix the MEDM screenshot that would be useful.

  15777   Tue Jan 26 10:58:30 2021 gautamUpdateSUSMC2 tickler stuck on

For whatever reason, the autolocker didn't turn the tickle off for several hours. Seems to work okay now. The linked plot suggests that the coil balancing on MC2 is pretty lousy.

  15783   Thu Jan 28 22:34:21 2021 gautamUpdateSUSDe-whitening

Summary:

  1. We will need de-whitening filters for the BHD relay optics in order to meet the displacement noise requirements set out in the DRD. I think these need not be remotely switchable (depends on specifics of LO phase control scheme). SR2, PR2 and PR3 can also have the same config, and probably MC1, MC3 as well.
  2. We will need de-whitening filters for the non test mass core IFO optics (PRM, SRM, BS, and probably MC2).
  3. I am pretty sure we will not be able to have sufficient DAC range for the latter class of optics if we have to:
    1. Supply the DC bias.
    2. Do the LSC and ASC actuation in the presence of reasonable sensing noise levels.
    3. Engage de-whitening to low-pass-filter the DAC noise at ~200 Hz.

Details:

Attachment #1 shows the DAC noise models for the General Standards 16-bit and 18-bit DACs we are expecting to have.

  • The 16-bit model has been validated by me at the 40m a few years ago.
  • We have never used the 18-bit flavor at the 40m, and there are all manner of quirks apparently related to zero crossings and such. So the noise may be up to x2 higher (we won't have as much freedom necessarily as the sites to bias the DAC on one side of the zero crossing if we also need to use the same DAC channel to supply the DC bias current for alignment.

Attachment #2 shows the expected actuation range for DC optic alignment, assuming we use the entire DAC range for this purpose.

  • Clearly, we need to do other things with the same DAC channels as well, so this is very much an upper bound of what will be possible.
  • Let's assume we will not go lower than 100ohms.
  • For all new optics we are suspending, we should aim to get the pitch balancing to within 500urad. With a 2x2m=4m optical lever arm, this corresponds to a 2mm spot shift. Should be doable.
  • This could turn out to be a serious problem for PRM, BS and SRM if we hope to measure squeezing - the <AUX DOF>-->DARM coupling could be at the level of -40dB, and at 200 Hz, the DAC noise would result in PRCL/MICH/SRCL noise at the level of ~10^-15m/rtHz, which would be 10^-17m/rtHz in DARM. I don't think we can get 20dB of feedforward cancellation at these frequencies. For demonstrating locking using a BHD error signal, maybe this is not a big deal.

Attachment #3 shows the current and proposed (by me, just a rough first pass, not optimized in any way yet) de-whitening filter shapes. These shapes can be tweaked for sure.

  • The existing de-whitening filter is way too aggressive. FWIW, the DRD "models" a "4th order Chebyshev low pass filter" which doesn't exist anywhere as far as I know.
  • Since the DAC noise is below 1 uV/rtHz at all frequencies of interest, we never need to have >60dB de-whitening anywhere as the input referred noise of any circuit we build will exceed 1 nV/rtHz.
  • I propose 3 poles, 3 zeros. In the plot, these poles are located at 30Hz, 50Hz, 2kHz, and the zeros are at 300 Hz, 300 Hz, 800 Hz. 
  • The de-whitening is less agressive below 100 Hz, where we still need significant LSC actuation ability. Considering the sensing noise levels at the 40m, I don't know if we can have reasonable LSC and ASC loop shapes and still have the de-whitening.
  • Once again, PRM, SRM and BS will be the most challenging.
  • For the BHD relay optics, once we have the de-whitening, we won't have the option of turning on a high-frequency (~kHz) dither line because of insufficient DAC range. 

Attachment #4 puts everything into displacement noise units. The electronics noise of the coil driver / de-whitening circuit have not been included so at high frequencies, the projection is better than what will actually be realizable, but still well below the BHD requirement of 3e-17 m/rtHz.

Attachment 1: DACnoiseModels.pdf
DACnoiseModels.pdf
Attachment 2: actuationRange.pdf
actuationRange.pdf
Attachment 3: deWhiteTFs.pdf
deWhiteTFs.pdf
Attachment 4: dispNoiseModels.pdf
dispNoiseModels.pdf
  15786   Mon Feb 1 12:30:21 2021 gautamUpdateElectronicsMore careful characterization

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. 

Attachment 1: HVPS.pdf
HVPS.pdf
Attachment 2: HV_testckt.pdf
HV_testckt.pdf
Attachment 3: totalNoise.pdf
totalNoise.pdf
  15788   Tue Feb 2 17:09:17 2021 yehonathanUpdateBHDSOS assembly

I set up a working area on the table next to the south flow bench (see attachment). I also brought in a rolling table for some extra space.

I covered all the working surfaces with a foil from the big roll between 1x3 and 1x4.

I took the SOSs, SOS parts and the OSEMS from the MC2 table to the working area.

I cleaned some LN Allen keys with isopropanol and put them on the working table, please don't take them.

Attachment 1: 20210202_165501.jpg
20210202_165501.jpg
Attachment 2: 20210202_162452.jpg
20210202_162452.jpg
  15790   Tue Feb 2 18:24:54 2021 KojiUpdateBHDSOS assembly

You can remove the components of the optical table enclosure (black ones) and use the optical table as your working area too.

 

  15791   Tue Feb 2 23:29:35 2021 KojiUpdateCDSCDS crash and CDS/IFO recovery

I worked around the racks and the feedthru flanges this afternoon and evening. This inevitably crashed c1lsc real-time process.
Rebooting c1lsc caused multiple crashes (as usual) and I had to hard reboot c1lsc/c1sus/c1ioo
This made the "DC" indicator of the IOPs for these hosts **RED**.

This looked like the usual timing issue. It looked like "ntpdate" is not available in the new system. (When was it updated?)

The hardware clock (RTC) of these hosts are set to be PST while the functional end host showed UTC. So I copied the time of the UTC time from the end to the vertex machines.
For the time adjustment, the standard "date" command was used

> sudo date -s "2021-02-03 07:11:30"

This made the trick. Once IOP was restarted, the "DC" indicators returned to **Green**, restarting the other processes were straight forward and now the CDS indicators are all green.

controls@c1iscex:~ 0$ timedatectl
      Local time: Wed 2021-02-03 07:35:12 UTC
  Universal time: Wed 2021-02-03 07:35:12 UTC
        RTC time: Wed 2021-02-03 07:35:26
       Time zone: Etc/UTC (UTC, +0000)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

NTP synchronization is not active. Is this OK?


With the recovered CDS, the IMC was immediately locked and the autolocker started to function after a few pokes (like manually running of the "mcup" script). However, I didn't see any light on the AS/REF cameras as well as the test mass faces. I'm sure the IMC alignment is OK. This means the TTs are not well aligned.

So, burtrestored c1assepics with 12:19 snapshot. This immediately brought the spots on the REFL/AS.

Then the arm were aligned, locked, and ASSed. I tried to lock the FP arms. The transmissions were at the level of 0.1~0.3. So some manual alignment of ITMY and BS were necessary. After having the TRs of ~0.8, I still could not lock the arms. The signs of the servo gains were flipped to -0.143 for X arm and -0.012 for Y arm, and the arms were locked. ASS worked well and the ASS offsets were offloaded to the SUSs.

 

  15792   Wed Feb 3 15:24:52 2021 gautamUpdateCDSCDS crash and CDS/IFO recovery

Didn't get a chance to comment during the meeting - This was almost certainly a coincidence. I have never had to do this - I assert, based on the ~10 labwide reboots I have had to do in the last two years, that whether the timing errors persist on reboot or not is not deterministic. But this is beyond my level of CDS knowledge and so I'm happy for Rolf / Jamie to comment. I use the reboot script - if that doesn't work, I use it again until the systems come back without any errors.

Quote:

This looked like the usual timing issue. It looked like "ntpdate" is not available in the new system. (When was it updated?)

The hardware clock (RTC) of these hosts are set to be PST while the functional end host showed UTC. So I copied the time of the UTC time from the end to the vertex machines.
For the time adjustment, the standard "date" command was used

> sudo date -s "2021-02-03 07:11:30"

This made the trick. Once IOP was restarted, the "DC" indicators returned to **Green**, restarting the other processes were straight forward and now the CDS indicators are all green.

I don't think this is a problem, the NTP synchronization is handled by timesyncd now.

Quote:

NTP synchronization is not active. Is this OK?

I defer restoring the LSC settings etc since I guess there is not expected to be any interferometer activity for a while.

  15794   Wed Feb 3 18:53:31 2021 KojiUpdateCDSCDS crash and CDS/IFO recovery

Really!? I didn't reboot the machines between "sudo date" and "rtcds start c1x0*". I tried rtcds. If it didn't work, it used date. Then tried rtcds. (repeat) The time was not synched at all wrt the time zones and also the time. There were 1~3 sec offset besides the TZ problem.

 

  15795   Wed Feb 3 21:28:02 2021 gautamUpdateCDSCDS crash and CDS/IFO recovery

I am just reporting my experience - this may be a new failure mode but I don't think so. In the new RTCDS, the ntp server for the FEs are the FB, to which they are synced by timesyncd. The FB machine itself has the ntpd service installed, and so is capable of synching to an NTP server over the internet, but also serving as an NTP server for the FEs. The timesyncd daemon may not have started correctly, or the NTP serving from FB got interrupted (for example), but that's all just speculation.

  15796   Thu Feb 4 15:14:55 2021 YehonathanUpdateBHDSOS assembly

I gathered all the components I could find from the SOS towers and the cleanroom and put it all on the table next to the flow bench (See attachment).

I combed through the cleanroom cabinet for SOS parts but didn't find all the parts listed in the procurement spreadsheet. I did find some extra items that were not listed.

This table compares the quantities in the spreadsheet to the quantities collected on the table. Green rows are items I found more than in the procurement spreedsheet while red rows are items I found less.

ITEM DCC # Qty required Qty in procurement spreadsheet How much I found
SENSOR/ACTUATOR PLATE D960002 14 21 21
SUSPENSION BLOCK D960003 7 9 9
TOWER BASE D960004 7 10 11
RIGHT SIDE PLATE D960005 7 12 13
LEFT SIDE PLATE D960006 7 12 13
UPPER MIRROR CLAMP D960007 7 8
7+1 teflon
LOWER CLAMP D960008-1 7 8 8
LOWER CLAMP, OPPOSITE D960008-2 7 8 8
WIRE CLAMP 1205308-1 10 17 9
CLAMP, SUSPENSION BLOCK D960134 14 19 21
STIFFENER PLATE D960009 7 9 9
DUMBBELL STANDOFF D970075 50 10 7
SAFETY STOP, LONG D970313 14 2 10
OSEM assy D960011 35 2 13 wire wound osem housings (gold)
WIRE STANDOFF D970187 20 7 0
GUIDE ROD D970188 10 9 0
MAGNET D960501 50 54 51 rusted + 37 slightly rusted. Didn't put on table
SAFETY STOP, SMALL D970312 28 0 4
SAFETY STOP D970311 28 0
16+9 stained w/o spring
SS Spring Plunger 8498A999 35 4 27
Attachment 1: 20210204_144007.jpg
20210204_144007.jpg
  15798   Wed Feb 10 14:14:58 2021 gautamUpdateElectronicsCustom cables received

We received the custom cables to test the new suspension electronics. They are under my desk. So we are ready.

This batch was a small one - the company says that they can make molded cables if we have a minimum order, something to consider I gues.s.


Update 1900 11 Feb: I verified that the pin outs of the cables are as we intended (for one set of each type of cable). Because this was a small order, the connectors have metal shells, and so for cable #2 (sat box to flange), the two shells are shorted to each other. I can't verify if the shield is isolated from the shell on J5 without cutting open the cable. One thing that occurred to me is that we should give pins 5,8,11 on J4 and 16,20,24 on J5 (respectively) unique identifiers. They should only be shorted to GND on the circuit board itself. To be fixed for the next iteration. I uploaded some photos here.

I was unable to measure the capacitance of the cable using the LCR meter, and didn't opt to try any other method.

Attachment 1: satWiring.pdf
satWiring.pdf
  15802   Wed Feb 10 21:14:03 2021 gautamUpdateElectronicsProduction version of the HV coil driver tested

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.

Attachment 1: inputDiffRecTF.pdf
inputDiffRecTF.pdf
Attachment 2: LVnoises.pdf
LVnoises.pdf
Attachment 3: totalNoise.pdf
totalNoise.pdf
Attachment 4: timeDomainTests.pdf
timeDomainTests.pdf
  15805   Thu Feb 11 18:21:39 2021 gautamUpdateSUSMC suspension glitches

MC1 suspension is glitching again, so this is a good chance to install the new sat box and test it in the field.

  15806   Fri Feb 12 15:03:48 2021 JordanUpdateSUSCoM on 3"->2" Adapter Ring for SOS

As it currently stands the Center of Mass of the Adapter Ring/Optic assembly is 0.0175" out of the plane formed by the suspension wire. See Attachments. The side plate, along with the EQ stops are hidden to show the CoM and the plane.

Note: The changes discussed in the meeting with Calum have not been added and are a work in progress. These changes include:

- Adding a 45 deg chamfer to the both parallel faces of the adapter ring. This along with a modified bracket for the EQ stops will allow for easier adjustment of the screws. 

- Potentially changing material of adapter ring to stainless stell to more accurately emulate the mass of a 3" optic.

- Different adjustment mechanism of the "dumbell" at bottom of adapter ring to something similar to the VOPO suspension (will need to consult Calum further)

Attachment 1: Screenshot_(1).png
Screenshot_(1).png
Attachment 2: Screenshot_(3).png
Screenshot_(3).png
Attachment 3: CoM.PNG
CoM.PNG
  15808   Tue Feb 16 13:13:39 2021 YehonathanUpdateBHDSOS assembly

Gautam pointed out that there are extra Sm-Co magnets stored in the clean optics cabinet.

I took the magnet box out and put it on the rolling table next to south flow bench. The box contains 3 envelopes with magnets.

They are labelled as following:

FLUX 94 - 50 parts

FLUX 93 - 10 parts

FLUX 95 - 40 parts

(What is FLUX??)

The box also contains some procurement documents.

The clean and bake dcc says :

1. Ultrasonic clean in methanol for 10 minutes

2. Bake in vacuum at 177 C° for 96 hours

Should we go ahead with the C&B?

  15809   Tue Feb 16 14:56:44 2021 gautamUpdateSUSaLIGO Sat Amp installed, powered

[jordan, gautam]

  • Ran 60ft long cables from 1X4 to MC1/MC3 chamber flange, via overhead cable tray, and top of PSL enclosure for the last ~20ft. Note that it may be that the overhead cable trays cannot support the weight of the cables for 15 SOSs (total 30 shielded cables with 37 wires as twisted pairs) when we eventually add the optics for the BHD upgrade.
  • Installed aLIGO satellite amplifer in 1X4.
  • Tapped +/-20 V (which is the available voltage closest to the required +/-18V). For this, the Sorensens were powered down, and the actual taps were made from the fusable blocks powering the Trillium interface box. We made sure to leave an extra slot so that this kind of additional headache is not required for the next person doing such work.
  • Once installed, I plugged in the dummy suspension box and verified that the unit performs as expected. 
  • Some photos of the installation are here.

After this work, the IMC locked fine, the AS camera has the Michelson fringing, the fast CDS indicators are all green, and the seismometer BLRMS all look good - therefore, I claim no lasting damage was done as a direct result of today's work at 1X4. I will connect up the actual suspension at my leisure later today. Note that the MC1 glitches seem to have gone away, without me doing anything about it. Nevertheless, I think it's about time that we start testing the new hardware. 


Unrelated to this work: while I was testing some characteristics of the MC1 suspension (before we did any work in the VEA, you can see the timestamp in the ndscope), I noticed that the MC1 UL coil channel cannot actually be used to actuate on the optic. The coil driver Vmon channel demonstrates the appropriate response, which means that the problem is either with the Satellite box (it is just a feedthrough, so PCB trace damaged?) or with the OSEM itself (more likely IMO, will know more once I connect the new Satellite Amplifier up). I only show comparison for UL vs UR, but I checked that the other coils seem to be able to actuate the optic. This means we have been running for an indeterminate amount of time with only 3 face actuators on MC1, probably related to me having to do this work


Also unrelated to this work - while poking around at 1X5 rear, I noticed that the power connections to the existing Satellite Boxes are (understatedly) flaky, see connections to T1-T4 in Attachment #2..

Attachment 1: MC1_deadUL.png
MC1_deadUL.png
Attachment 2: IMG_9100.jpg
IMG_9100.jpg
  15810   Tue Feb 16 15:29:01 2021 KojiUpdateBHDSOS assembly

The curie temp of SmCo seems about x2 (in K) of the one for NdFeB. i.e. 600K vs 1000K. So I believe 177degC = 450K is not an issue. Just make sure the curie temp, referring the specific property for the magnets from this company. (You already know the company from the procurement doc). It'd be great if you upload the doc on the 40m wiki.

  15811   Tue Feb 16 22:59:36 2021 YehonathanUpdateBHDSOS assembly

Done.

Also, the magnets are nickel-plated. I guess that doesn't matter for the baking (Curie temp of 355 °C)?

Quote:

The curie temp of SmCo seems about x2 (in K) of the one for NdFeB. i.e. 600K vs 1000K. So I believe 177degC = 450K is not an issue. Just make sure the curie temp, referring the specific property for the magnets from this company. (You already know the company from the procurement doc). It'd be great if you upload the doc on the 40m wiki.

 

  15812   Wed Feb 17 13:59:35 2021 gautamUpdateDetCharSummary pages

The summary pages had failed because of a conda env change. We are dependent on detchar's conda environment setup to run the scripts on the cluster. However, for some reason, when they upgraded to python3.9, they removed the python3.7 env, which was the cause of the original failure of the summary pages a couple of weeks ago. Here is a list of thoughts on how the pipeline can be made better.

  1. The status checking is pretty hacky at the moment.
    • I recommend not using shell via python to check if any condor jobs are "held".
    • Better is to use the dedicated python bindings. I have used this to plot the job durations, and it has worked well.
    • One caveat is that sometimes, there is a long delay between making a request via a python command, and condor actually returning the status. So you may have to experiment with execution times and build some try/except logic to catch "failures" that are just the condor command timing out and not an actual failure of the summare jobs.
  2. The status check should also add a mailer which emails the 40m list when the job is held. 
    • With htcondor and python, I think it's easy to also get the "hold reason" for the job and add that to the mailer.
  3. The job execution time command is not executing correctly anymore - for whatever reason, the condor_history command can't seem to apply the constraint of finding only jobs run by "40m", although running it without the constraint reveals that these certainly exist. Probably has to do with some recent upgrade of condor version or something. This should be fixed.
  4. We should clear the archive files regularly. 
    • The 40m home directory on the cluster was getting full. 
    • The summary page jobs generate a .h5 archive of all the data used to generate the plots. Over ~1 year, this amounts to ~1TB.
    • I added the cleanArchive job to the crontab, but it should be checked.
    • Do we even need these archives beyond 1 day? I think they make the plotting faster by saving data already downloaded locally, but maybe we should have the cron delete all archive 
  5. Can we make our own copy of the conda env and not be dependent on detchar conda env? The downside is that if something dramatic changes in gwsumm, we are responsible for debugging ourselves.

Remember that all the files are to be edited on nodus and not on the cluster.

  15813   Wed Feb 17 13:59:43 2021 KojiUpdateSUSCoM on 3"->2" Adapter Ring for SOS

Note from today's meeting:

1. Can we adjust the thickness of the cylindrical hole for the mirror to move the COM in the plane of the wires. (We should be able to do that)

and

2. Please check how much we can displace the COM by the bottom dumbbell.

  15814   Wed Feb 17 16:11:53 2021 gautamUpdateSUSaLIGO Sat Amp installed, powered

There is some non-trivial sign flipping in the sensors/coils in this new setup because it is a hybrid one with the old interfacing electronics (D000210, D010001) and the new Satellite Amplifier (D080276). So I haven't yet gotten the damping working. I am leaving the PSL shutter closed and will keep working on this today/tomorrow. I have made various changes to the c1mcs realtime model and the c1susaux database record where MC1 is concerned. I have backups of the old ones so we can always go back to that if we so desire.

In the meantime, the PSL shutter is closed and there is no light to the IFO.


Update 1700: I've implemented some basic damping and now the IMC is now locked. The WFS loop runs away when I enable it, probably some kind of weird interaction with the (as of now untuned) MC1 local damping loops. I will write up a more detailed report later.


Update 2300: Did the following:

  1. Re-calibrated the cts2um filter in all SENSOR filter banks to account for the increased transimpedance and LED drive current. I judged the overall scaling to be x0.25 but this can be calibrated against the bounce peak height for example (it lines up pretty well).
  2. Re-measured the input matrix - it was very different from what was loaded. I am measuring this again overnight for some consistency.
  3. Re-tuned the damping gains. Now the optic damps well, and the loops seem file to me, both via broadband noise injection TF and by step response metrics.
  4. Yet, the WFS servo cannot be enabled. The WFS signal is summed in before the output matrix so I don't know why this would have a different behavior compared to the local damping, or indeed, why this has to be changed. Will need some (WFS) sensing/actuation matrix measurements to know more.

Dropping this for tonight, I'll continue tomorrow. Meanwhile, the OSEM input matrix measurement is being repeated overnight. PSL shutter is closed.

  15816   Thu Feb 18 15:15:12 2021 yehonathanUpdateSUSOSEM testing for SOSs

I am setting up a testing rig for the OSEMs we recently obtained. I found the schematic for the OSEM assembly from which the pin assignment can be read.

I connected the OSEM's pin plate to a female DB15 on a breakout board. I find the pin assignment (attachment 1, sorry for the image quality) to be:

1 PD Cathode
2 LED Anode
3 Coil end
4 PD Anode
5 LED Cathode
6 Coil Start

There are several things that need to be done for each OSEM.

1. Measuring inductance of the coils. I checked that the measurement wires don't add any measurable inductance.

2. Check that the PDs and LEDs are alive (e.g. check forward voltage drop with fluke)

3. Energize the LED and PD.

4. Check PD DC level. For this, I might need the satellite box amplifier.

5. Check LED spot position on the PD.

6. Re-engrave OSEM S/N if needed.

OSEM # Coil Inductance (mH) Coil resistance (ohm) PD forward voltage (V) LED forward voltage (V)
280 2.87 14.1 0.63 1.1
         
         

I still need to figure a sensible scheme for points 3-5.

 

 

Attachment 1: OSEM_Pin_Plate.png
OSEM_Pin_Plate.png
  15817   Thu Feb 18 15:33:21 2021 gautamUpdateSUSaLIGO Sat Amp installed, powered and commissioned

The WFS servo was recommissioned. The matrix can be tuned a bit more, but for now, I've recovered the old performance and the alignment doesn't seem to be running away, so I defer further tuning for later. The old Satellite box was handed over to Yehonathan for his characterization of the "spare" OSEMs.

This finishes the recovery of the MC1 suspension, I am now satisfied that the local damping loops are performing satisfactorily, that the WFS servo is also stable, and that POX/POY locking is recovered. On MC1, we even have 4 actuatable face OSEMs and the PIT(YAW) bias adjust slider even moves the optic in PIT(YAW), what a luxury. 

I've SDFed all the changes, and have backup of the old realtime model and C1SUSAUX_MC1 database files if we want to go back for whatever reason. The changes required to make this suspension work are different from what will eventually be required for the BHD suspensions (because of the hybrid iLIGO/aLIGO electronics situation), so I will not burden the readers with the tedious details.

  15818   Thu Feb 18 18:05:04 2021 gautamUpdateSUSaLIGO Sat Amp characterization

Before installation, I performed a bunch of tests on the aLIGO sat amp. All the measurements were made with the dummy suspension box substituting for an actual suspension. Here are the results.

Attachment #1: Transimpedance amplifier noises.

  • Measurement setup: J7 of the Satellite Amp goes to J9 on D1900068 front end (even though the connector is actually labelled "J3" on the box we have - maybe a versioning problem?). The outputs then go to a G=100 SR560 in AC coupled mode (the main purpose here was to block the large DC from the SR785, but I tacked on G=100 while I was at it).  
  • Top panel shows the raw measured voltages.
  • The bottom panel does a bunch of transformations:
    • Undoes the z:p = 3:30 Hz whitening on board the sat amp.
    • Undoes the G=100 gain of the SR560, and the AC coupling poles/zeros of SR560 and SR785.
    • Converts from voltage to current by dividing by the transimpedance gain, 242 kohms. 
  • Some model curves are shown for comparing to the measured spectra. It may be possible that we don't need to modify the nominal z:p = 0.4:10 Hz - I don't think the nominal seismic level will saturate the output even with the 0.4:10 Hz whitening, and it gives us even more clearance to the ADC noise (although we don't need it, we are gain limited at those frequencies, this is mostly a suggestion to reduce the workload).
  • The neon green curve is measured with the actual MC1 suspension plugged in, local damping enabled. It doesn't line up with the nosie floor of the bench tests, probably because the cts/um conversion factor could be off by some factor? Around 1 kHz, you can also see some broad peaks that are reminiscent of those seen in the MC_F spectrum after the c1psl Acromag upgrade. I hypothesize this is due to some poor grounding. Hopefully, once we get rid of the single-ended sending/receiving components in the suspension electronics chain, these will no longer be an issue.

Attachment #2: LED drive current source noises. I mainly wanted to check a claim by Rich in a meeting some time ago that the LED intensity fluctuations are dominated by inherent LED RIN, and not by RIN on the drive current. 

  • Measurement setup: a pair of pomona mini-grabbers was used to clip onto TP3. I found the voltage noise to be sufficiently high that no preamplification was required, and the DC level was <1V, so I just used the SR785 in AC coupled mode. 
  • The dummy suspension box was being driven while the measurement was being made (so the current source is loaded).
  • One channel (CH6) shows anomalously high nosie. I confirmed this was present even after the box was plugged in for ~1 day, so can't be due to any thermal / equilibriating transients.
  • I didn't check for consistency at the monitor testpoint, but that is exposed even with the MC1 suspension plugged in, so we can readily check. Anyways, from the corresponding photodiode curve in Attachment #1, it would seem that this excess RIN in the drive current has no measurable effect on the intensity fluctuations of the LED (the DC value of the paired PD is consistent with the others, ~6V DC). I must say I am surprised by this conclusion. I also checked for coherence between TP3 and the PD output using the SR785, and found none. 🤔 
  • Nevertheless, for the remaining channels, it is clear that the drive current is not shot noise limited for <1kHz. This isn't great. One possible reason is that the collector voltage to Q1 is unregulated (my modeling suggests only ~10dB rejection of collector voltage fluctuations at the output). I believe the current source designed by Luis for A+ makes some of these improvements and so maybe Rich was referring to that design, and not the aLIGO Satellite Amplifier flavor we are using. Anyways, this is just academic I think, the performance is the unit is fine for our purposes.

I will update with the MC1 suspension characterization (loop TFs, step responses etc) later.

Attachment 1: OSEMnoise.pdf
OSEMnoise.pdf
Attachment 2: LEDdriveNoise.pdf
LEDdriveNoise.pdf
  15819   Thu Feb 18 20:20:25 2021 KojiUpdateSUSaLIGO Sat Amp characterization

Yeah, it's really inconsistent. You had 35mA LED drive and the current noise of the noisy channel was 5e-7 A/rtHz at 1Hz. The RIN is 1.4e-5 /rtHz. The approx. received photocurrent is 30uA as we discussed today and this should make the noise around 4e-10 A/rtHz at 1Hz. However, the readout noise level is better than this level. (well below 1e-10 A/rtHz)

BTW, the IMC seemed continuously locked for 5 hours. Good sign.

  15821   Fri Feb 19 12:21:04 2021 YehonathanUpdateBHDSOS assembly

A summary of things that need to be fabricated/purchased/done:

Part What needs to be done How much more needed
SUSPENSION BLOCK Fabricate SS dowel pins for 1 suspension block. 2X(diameter 0.094"+-0.002, length 0.38"+-0.01)+2X(diameter 0.188"+-0.002, length 0.5"+-0.01)
WIRE CLAMP If using the opposite side is acceptable, we have enough.  
DUMBBELL STANDOFF Fabricate. Schematics. Need to check the size is compatible with the magnets we have. 40 + 10 for double stacking of side dumbbells. With the existing dumbbells, we'll have 18 spares.
SAFETY STOP, LONG Fabricate or buy. Schematics 4
OSEM assy Check if we have 35. Schematics  
SAFETY STOP, SMALL Fabricate or buy. Schematics 24
SAFETY STOP Fabricate or buy. Schematics 12
SS Spring Plunger Buy from McMaster. Find and check custom plungers around the X arm. 8
4-40 3/8" Ag SHCS Buy from uccomponents.com 30
4-40 1/2 Ag SHCS Buy from uccomponents.com 60
1/4-20 3/4 Ag SHCS Buy from uccomponents.com 150
1/4-20 5/4 Ag SHCS Buy from uccomponents.com 30
1/4 SS Lock Washer Buy from McMaster 30
1/4 SS Lock Wassher (Reduced OD) Buy from McMaster 30
Viton Tips Need to find stock Not sure. Existing eq stops have phosphor bronze springs. Should all of them be replaced with Viton?
Steel Music Wire There are 500ft of wire (enough for many SOSs) in a desiccator somewhere according to this elog  

 

  15822   Fri Feb 19 13:38:26 2021 gautamUpdateLSCPRFPMI

I forgot that I had already done some investigation into recovering the PRFPMI lock after my work on the RF source. I don't really have any ideas on how to explain (or more importantly, resolve) the poor seperation of MICH and PRCL sensed in our 3f (but also 1f) photodiodes, see full thread here. Anyone have any ideas? I don't think my analysis (=code) of the sensing matrix can be blamed - in DTT, just looking the spectra of the _ERR_DQ channels for the various photodiodes while a ssingle frequency line is driving the PRM/BS suspension, there is no digital demod phase that decouples the MICH/PRCL peak in any of the REFL port photodiode spectra.

  15823   Fri Feb 19 15:17:51 2021 JordanUpdateSUSCoM Range on 3"->2" Adapter Ring for SOS

Adjusting the thickness of the cylindrical hole for the mirror on the 2" optic sleeve, from .6875" to .61" thick, moves the CoM to 0.0003" out of plane from the suspension wire. This is with the dumbell at its neutral point.

How close to zero do we need this to be? More fine tuning of that thickness can get it to zero, but this would require much tighter machining tolerance on that hole depth.

Moving the dumbell towards the back of the SOS assembly (noted as negative direction, with origin at the plane formed by the wires), moves the CoM to -0.002" from the plane.

Moving the dumbell towards the front of the SoS assmebly (positive direction wrt the plane formed by the suspension wire), moves the CoM to +0.0022" from the plane.

So the total adjustment range with the dumbell is -0.002"to 0.0022", with the plane formed by the wires as the origin.

See Attachments

Attachment 1: Neutral_Point.png
Neutral_Point.png
Attachment 2: Dumbell_Max_Negative_Travel.png
Dumbell_Max_Negative_Travel.png
Attachment 3: Dumbell_Max_Positive_Travel.png
Dumbell_Max_Positive_Travel.png
ELOG V3.1.3-