40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 23 of 335  Not logged in ELOG logo
ID Date Author Type Category Subject
  15742   Mon Dec 21 09:28:50 2020 JamieConfigurationCDSUpdated CDS upgrade plan
Quote:

Attached is the layout for the "intermediate" CDS upgrade option, as was discussed on Wednesday. Under this plan:

  • Existing FEs stay where they are (they are not moved to a single rack)

  • Dolphin IPC remains PCIe Gen 1

  • RFM network is entirely replaced with Dolphin IPC

Please send me any omissions or corrections to the layout.

I just want to point out that if you move all the FEs to the same rack they can all be connected to the Dolphin switch via copper, and you would only have to string a single fiber to every IO rack, rather than the multiple now (for network, dolphin, timing, etc.).

  15741   Sat Dec 19 20:24:25 2020 gautamUpdateElectronicsWFS hardware install

I installed 4 chassis in the rack 1X2 (characterization on the E-bench was deemed satisfactory, I will upload the analysis later). I ran out of hardware to make power cables so only 2 of them are powered right now (1 32ch AA chassis and 1 WFS head interface). The current limit on the +24V Sorensens was raised to allow for similar margin to the limit with the increased current draw.

Remaining work:

  1. Make 2 more power cables for ISC whitening chassis and quad demod chassis.
  2. Make a 2x 4pin LEMO-->DB9 cable to digitize the FSS and PMC diagnostic channels with the new AA chassis. If RnD cables has a very short turnaround time, might be worth it to give this to them as well.
  3. Connect ADC1 on c1ioo machine to new AA chassis (transfer SCSI cable from existing AA unit to the new one). This will necessarily involve some model changes as well.
  4. Make a short cable to connect 55 MHz output from RFsource box to the LO input on the quad demod chassis.
  5. Install the WFS head on the AS table at a suitable location. Probably will need a focusing lens as well. 
  6. Connect WFS head to the signal processing electronics (the cables were already laid out by Jordan and I).
  7. Make the necessary CDS model changes (WFS filters, matrices, servos etc). I personally don't see the need for a new model but if anyone feels strongly about separating the IMC WFS and AS WFS we can set up another model.
  8. Commission the system.

While I definitely bumped various cables, I don't seem to have done any lasting damage to the CDS system (the RFM errors remain of course).

  15740   Sat Dec 19 02:42:56 2020 KojiUpdate New SMA cables on order

Our favorite (flexible) RF cable is Belden's 1671J (Jacketed solder-soaked coax cable). It is compatible RG405. I'm not sure if there is off-the-shelf SMA cables with 1671J.

 

  15739   Sat Dec 19 00:25:20 2020 JonUpdate New SMA cables on order

I re-ordered the below cables, this time going with flexible, double-shielded RG316-DS. Jordan will pick up and return the RG-405 cables after the holidays.

Quote:

As requested, I placed an order for an assortment of new RF cables: SMA male-male, RG405.

  • x3 12"
  • x3 24"
  • x2 48"
  15738   Fri Dec 18 22:59:12 2020 JonConfigurationCDSUpdated CDS upgrade plan

Attached is the layout for the "intermediate" CDS upgrade option, as was discussed on Wednesday. Under this plan:

  • Existing FEs stay where they are (they are not moved to a single rack)

  • Dolphin IPC remains PCIe Gen 1

  • RFM network is entirely replaced with Dolphin IPC

Please send me any omissions or corrections to the layout.

Attachment 1: CDS_2020_Dec.pdf
CDS_2020_Dec.pdf
Attachment 2: CDS_2020_Dec.graffle
  15737   Fri Dec 18 10:52:17 2020 gautamUpdateCDSRFM errors

As I was working on the IFO re-alignment just now, the rfm errors popped up again. I don't see any useful diagnostics on the web interface.

Do we want to take this opportunity to configure jumpers and set up the rogue master as Rolf suggested? Of course there's no guarantee that will fix anything, and may possibly make it impossible to recover the current state...

Attachment 1: RFMdiag.png
RFMdiag.png
  15736   Thu Dec 17 15:23:56 2020 gautamUpdateASCWFS head characterization

Summary:

I think the WFS head performs satisfactorily.

  • The (input-referred) dark noise level at the operating frequency of 55 MHz is ~40pA/rtHz (modelled) and ~60 pA/rtHz (measured, converted to input-referred). See Attachment #1. Attachment #5 has the input referred current noise spectral densities, and a few representative shot noise levels.
  • The RF transimpedance gain at the operating frequency is ~500 ohms when driving a 50 ohm load (in good agreement with LTspice model). See Attachment #2 and Attachment #3.
  • The resonant gain to notch ratios are all > 30 dB, which is in line with numbers I can find for the WFS installed at the sites (and in good agreement with the LTspice model as well).
  • There are a few lines visible in the noise measurement. But these are small enough not to be a show-stopper I think.

Details and remarks:

  1. Attachment #4 shows a photo of the setup. 
    • The QPD used was S/N #84.
    • The heat sinks have a bunch of washers because the screw holes were not tappe at time of manufacture.
    • There isn't space to have 8 SMA feedthroughs in the D-shaped cutouts, so we can only have the 4 "RF HI" outputs without some major metalwork.
    • C9 has been remvoed in all channels (to isolate the "TEST INPUT").
  2. I found that some quadrants displayed a ~35 MHz sine-wave of a few mV pk-pk when I had the back of the enclosure off (for tuning the notches). The hypothesis is that this was due to some kind of stray capacitance effect. Anyways, once I closed everything up, for the noise measurement, this peak was no longer visible. With an HP8447A preamp, I measured an RMS voltage of ~2mV rms on an oscilloscope. After undoing the 20 dB gain of the amplifier, each quadrant has an output voltage noise of ~200 uVrms (as returned by the "measure" utility on the scope, I don't know the specifics of how it computes this). Point is, there wasn't any clear sine-wave oscillations like I saw on two channels when the lid was off. 
  3. Some of the lines are present during some measurement times but not others (e.g. Q4 blue vs red curve in Attachment #1). I was doing this work in the elec-bench area of the lab, right next to the network switches etc so not exactly the quietest environment. But anyway, I don't see anything in these measurements that suggest something is seriously wrong.
  4. In the transfer function measurements, above 150 MHz, there are all sorts of features. But I think this is a measurement artefact (stray cable capacitance etc) and not anything real in the RF signal path. Koji saw similar effects I believe, and I didn't delve further into it.
  5. The dark noise of the circuit is such that to be shot noise limited, each quadrant needs 10 mA of DC photocurrent. The light bulb we have has a max current rating of 0.25A, with which I could only get 3 mA DC per quadrant. So the 55 MHz sideband power needed to be shot noise limited is ~50 mW - we will never have such high power. But I think to have better performance will need a major re-work of the circuit design (finite Qs of inductors, capacitors etc).
  6. Regarding the transimpedance gains - in my earlier plots, I omitted the 50ohm input impedance of the AG4395A network analyzer. The numbers I report here are ~half of those earlier in this thread for this reason. In any case, I think this number is what is important, since the ADT-1-1 on the demod board RF input has an input impedance of 50ohm. 
  7. Regarding grounding - the RF ground on the head is actually isolated from the case pretty well. Two locations of concern are (i) the heat sinks for the voltage regulator ICs and (ii) the DB15 connector shield. I've placed electrically insulating (but thermally conducting) pads from TO220 mounting kits between both sets of objects and the case. However, for the Dsub connector, the shape of the pad doesn't quite fit all the way round the connector. So if I over-tighten the 4-40 mounting bolts, at some point, the case gets shorted to the RF ground, presumably because the connector deforms slightly and touches the case in a spot where I don't have the isolating pad installed. I think I've realized a tightness that is mechanically satisfying but electrically isolating.
  8. I will do the fitting at my leisure but the eye-fit is already suggesting that things are okay I think.

If the RF experts see some red flags / think there are more tests that need to be performed, please let me know. Big thanks to Chub for patiently supporting this build effort, I'm pleasantly surprised it worked.

Attachment 1: oNoise.pdf
oNoise.pdf
Attachment 2: Z_Hi.pdf
Z_Hi.pdf
Attachment 3: Z_Low.pdf
Z_Low.pdf
Attachment 4: IMG_9030.jpg
IMG_9030.jpg
Attachment 5: iNoise.pdf
iNoise.pdf
  15735   Tue Dec 15 12:38:41 2020 gautamUpdateElectronicsDC power strip

I installed a DC power strip (24 V variant, 12 outlets available) on the NW upright of the 1X1 rack. This is for the AS WFS. Seems to work, all outlets get +/- 24 V DC.

The FSS_RMTEMP channel is very noisy after this work. I'll look into it, but probably some Acromag grounding issue.

In the afternoon, Jordan and I also laid out 4x SMA LMR240 cables and 1x DB15 M/F cable from 1X2 to the NE corner of the AP table via the overhead cable trays.

  15734   Mon Dec 14 11:09:28 2020 YehonathanUpdateBHDMonte Carlo loop coupling Simulations

I spent a few hours monkeying around with the control filters. They are totally made up and also it's my first time trying to design control filters.

The OLTFs of the different length controls are shown in attachment 1.

The open-loop couplings of the DOFS to DARM are shown in attachment 2.

Note that in Lance/Pytickle the convention is that CLTFs are 1/(1 - G). Where G is the OLTF.

Quote:

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

 

 

Attachment 1: MCMC_LANCE_OLTFs.pdf
MCMC_LANCE_OLTFs.pdf
Attachment 2: MCMC_LANCE_OLCoupling2DARM.pdf
MCMC_LANCE_OLCoupling2DARM.pdf
  15732   Fri Dec 11 09:28:52 2020 ranaUpdateBHDMonte Carlo loop coupling Simulations

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

Quote:

I have rebuilt the MCMC simulation in an OOP fashion and incorporated Lance/Pytickle functionality into it. The usage of the MCMC now is much less messy, hopefully.

 

  15731   Thu Dec 10 22:46:57 2020 gautamUpdateASCWFS head assembled

The assembly of the head is nearly complete, I thought I'd do some characterization before packaging everything up too nicely. I noticed that the tapped holes in the base are odd-sized. According to the official aLIGO drawing, these are supposed to be 4-40 tapped, but I find that something in between 2-56 and 4-40 is required - so it's a metric hole? Maybe we used some other DCC document to manufacture these parts - does anyone know the exact drawings used? In the meantime, the circuit is placed inside the enclosure with the back panel left open to allow some tuning of the trim caps. The front panel piece for mounting the SMA feedthroughs hasn't been delivered yet so hardware-wise, that's the last missing piece (apart from the aforementioned screws).

Attachment #1 - the circuit as stuffed for the RF frequencies of relevance to the 40m.

Attachment #2 - measured TF from the "Test Input" to Quadrant #1 "RF Hi" output.

  • There is reasonable agreement, but not sure what to make of the gain mismatch at most frequencies.
  • The photodiode itself hasn't been installed yet, so there will be some additional tuning required to account for the interaction with the photodiode's junction capacitance.
  • I noticed that the Qs of the resonances in between the notches is pretty high in this config, but the SPICE model also predicts this, so I'm hopeful that they will be tamed once the photodiode is installed.
  • One thing that is worrying is the feature at ~170 MHz. Could be some oscillation of the LM opamp. All the aLIGO WFS test procedure documentation shows measurements only out to 100 MHz. Should we consider increasing the gain of the preamp from x10 to x20 by swapping the feedback resistor from 453 ohms to 1 kohm? Is this a known issue at the sites
  • Any other comments?

Update 11 Dec: For whatever reason, whoever made this box decided to tap 4-40 holes from the bottom (i.e. on the side of the base plate), and didn't thread the holes all the way through, which is why I was unable to get a 4-40 screw in there. To be fair the drawing doesn't specify the depth of the 4-40 holes to be tapped. All the taps we have in the lab have a maximum thread length of 9/16" whereas we need something with at least 0.8" thread length. I'll ask Joe Benson at the physics workshop if he has something I can use, and if not, I'll just drill a counterbore on the bottom side and use the taps we have to go all the way through and hopefully that does the job.

The front panel I designed for the SMA feedthroughs arrived today. Unfortunately, it is impossible for the D-sub shaped holes in this box to accommodate 8 insulated SMA feedthroughs (2 per quadrant for RF low and RF high) - while the actual SMA connector doesn't occupy so much space, the plastic mold around the connector and the nut to hold it are much too bulky. For the AS WFS application, we will only need 4 so that will work, but if someone wants all 8 outputs (plus an optional 9th for the "Test Input"), a custom molded feedthrough will have to be designed. 

As for the 170 MHz feature - my open loop modeling in Spice doesn't suggest a lack of phase margin at that frequency so I'm not sure what the cause is there. If this is true, just increasing the gain won't solve the issue (since there is no instability at least by the phase margin metric). Could be a problem with the "Test Input" path I guess. I confirmed it is present in all 4 quadrants.

Attachment 1: aLIGO_wfs_v5_40m.pdf
aLIGO_wfs_v5_40m.pdf
Attachment 2: TF_meas.pdf
TF_meas.pdf
  15730   Thu Dec 10 22:45:42 2020 gautamUpdateSUSMore spare OSEMs

I acquired several spare OSEMs (in unknown condition) from Paco. They are stored alongside the shipment from UF.

  15729   Thu Dec 10 17:12:43 2020 JonUpdate New SMA cables on order

As requested, I placed an order for an assortment of new RF cables: SMA male-male, RG405.

  • x3 12"
  • x3 24"
  • x2 48"

They're expected to arrive mid next week.

  15728   Thu Dec 10 16:24:13 2020 gautamUpdateEquipment loanNoliac PZT --> Paco

I gave one Noliac PZT from the two spare in the metal PMC kit to Paco. There is one spare left in the kit.

  15727   Thu Dec 10 14:48:00 2020 YehonathanUpdateBHDMonte Carlo Simulations

I have rebuilt the MCMC simulation in an OOP fashion and incorporated Lance/Pytickle functionality into it. The usage of the MCMC now is much less messy, hopefully.

I made an example that calculates the closed-loop noise-coupling from SRCL sensing and displacement to DARM in A+. I used the control filters that Kevin defined in his controls example.

The resulting noise budget is in attachment 1. The code is in the 40m/bhd git.

 

I also investigated why aLIGO simulations behave so different than the A+ simulation (See few previous elogs in this thread). That is why aLIGO results are much less variable, and the simulations in aLIGO barely pass the validity checks, while A+ simulations almost always pass.

The way I check for the validity of a kat model is by scanning all the DOFs and checking that the corresponding sensing RFPDs demodulated signals cross zero. Attachment 2 shows these scanning for 3 such RFPDS for 3 cases:

A+ model with maxtem = 2

ALigo model with maxtem = 2

ALigo model with maxtem = 'off'

It seems like the scanning curves for A+ and ALigo with no HOMs are well behaved and look like normal PDH signals, while the ALigo with maxtem = 2 curves look funky. I believe that the aLIGO+HOMS curves indicate that the IFO is not really in a good locking point. All the IFO lockings were done by using the locking methods straight out of the PyKat package. 

Attachment 1: MCMCLance_NoiseBudget_Example.pdf
MCMCLance_NoiseBudget_Example.pdf
Attachment 2: IFO_Check.pdf
IFO_Check.pdf
  15725   Thu Dec 10 14:29:26 2020 gautamUpdateVACUPS failure

I don't buy this story - P2 only briefly burped around GPStime 1291608000 which is around 8pm local time, which is when I was recovering the system.

Today. Jordan talked to Jon Feicht - apparently there is some kind of valve in the TP2 forepump, which only opens ~15-20 seconds after turning the pump on. So the loud sound I was hearing yesterday was just some transient phenomenon. So today morning at ~9am, we turned on TP2. Once again, PTP2 pressure hovered around 500 torr for about 15-20 seconds. Then it started to drop, although both Jordan and I felt that the time it took for the pressure to drop in the range 5 mtorr - 1 mtorr was unusually long. Jordan suspects some "soft-start" feature of the Turbo Pumps, which maybe spins up the pump in a more controlled way than usual after an event like a power failure. Maybe that explains why the pressure dropped so slowly? One thing is for sure - the TP2 controller displayed "TOO HIGH LOAD" yesterday when I tried the first restart (before migrating everything to the older UPS unit). This is what led me to interpret the loud sound on startup of TP2 to indicate some issue with the forepump - as it turns out, this is just the internal valve not being opened.

Anyway, we left TP2 on for a few hours, pumping only on the little volume between it and V4, and PTP2 remained stable at 20 mtorr. So we judged it's okay to open V4. For today, we will leave the system with both TP2 and TP3 backing TP1. Given the lack of any real evidence of a failure from TP2, I have no reason to believe there is elevated risk.

As for prioritising UPS swap - my opinion is that it's better to just replace the batteries in the UPS that has worked for years. We can run a parallel reliability test of the new UPS and once it has demonstrated stability for some reasonable time (>4 months), we can do the swap.


I was able to clear the FAULT indicator on the new UPS by running a "self-test". pressing and holding the "mute" button on the front panel initiates this test according to the manual, and if all is well, it will clear the FAULT indicator, which it did. I'm still not trusting this unit and have left all units powered by the old UPS.


Update 1100 Dec 11: The config remained stable overnight so today I reverted to the nominal config of TP3 pumping the annuli and TP2 backing TP1 which pumps the main volume (through the partially open RV2).

Quote:
 

According to the Tripp Lite manual, the FAULT icon indicates "the battery-supported outlets are overloaded." The failure of the TP2 dry pump appears to have caused this. After the dry pump failure, the rising pressure in the TP2 foreline caused TP2's current draw to increase way above its normal operating range. Attachment 1 shows anomalously high TP2 current and foreline pressure in the minutes just before the failure. The critical system-wide failure is that this overloaded the UPS before overloading TP2's internal protection circuitry, which would have shut down the pump, triggering interlocks and auto-notifications.

Attachment 1: vacDiag1.png
vacDiag1.png
  15724   Thu Dec 10 13:05:52 2020 JonUpdateVACUPS failure

I've investigated the vacuum controls failure that occurred last night. Here's what I believe happened.

From looking at the system logs, it's clear that there was a sudden loss of power to the control computer (c1vac). Also, the system was actually down for several hours. The syslog shows normal EPICS channel writes (pressure readback updates, etc., and many of them per minute) which suddenly stop at 4:12 pm. There are no error or shutdown messages in the syslog or in the interlock log. The next activity is the normal start-up messaging at 7:39 pm. So this is all consistent with the UPS suddenly failing.

According to the Tripp Lite manual, the FAULT icon indicates "the battery-supported outlets are overloaded." The failure of the TP2 dry pump appears to have caused this. After the dry pump failure, the rising pressure in the TP2 foreline caused TP2's current draw to increase way above its normal operating range. Attachment 1 shows anomalously high TP2 current and foreline pressure in the minutes just before the failure. The critical system-wide failure is that this overloaded the UPS before overloading TP2's internal protection circuitry, which would have shut down the pump, triggering interlocks and auto-notifications.

Preventing this in the future:

First, there are too many electronics on the 1 kVA UPS. The reason I asked us to buy a dual 208/120V UPS (which we did buy) is to relieve the smaller 120V UPS. I envision moving the turbo pumps, gauge controllers, etc. all to the 5 kVA unit and reserving the smaller 1 kVA unit for the c1vac computer and its peripherals. We now have the dual 208/120V UPS in hand. We should make it a priority to get that installed.

Second, there are 1 Hz "blinker" channels exposed for c1vac and all the slow controls machines, each reporting the machine's alive status. I don't think they're being monitored by any auto-notification program (running on a central machine), but they could be. Maybe there already exists code that could be co-opted for this purpose? There is an MEDM screen displaying the slow machine statuses at Sitemap > CDS > SLOW CONTROLS STATUS, pictured in Attachment 2. This is the only way I know to catch sudden failures of the control computer itself.

Attachment 1: TP2_time_history.png
TP2_time_history.png
Attachment 2: slow_controls_monitors.png
slow_controls_monitors.png
  15723   Thu Dec 10 11:17:50 2020 ChubUpdateVACUPS fault

I can't find anything in the manual that describes the nature of the FAULT message.  In fact, it's not mentioned at all.  If the unit detects a fault at its output, I would expect a bit more information.  This unit does a programmable level of input error protection, too, usually set at 100%.  Still, there is no indication in the manual whether an input issue would be described as a fault; that usually means a short or lifted ground at the output.

Quote:

Is that a fault code that you can decipher in the manual, or just a light telling you nothing but your UPS is dead?

  15722   Thu Dec 10 11:07:24 2020 ChubUpdateVACUPS fault

Is that a fault code that you can decipher in the manual, or just a light telling you nothing but your UPS is dead?

  15721   Wed Dec 9 20:14:49 2020 gautamUpdateVACUPS failure

Summary:

  1. The (120V) UPS at the vacuum rack is faulty.
  2. The drypump backing TP2 is faulty.
  3. Current status of vacuum system: 
    • The old UPS is now powering the rack again. Sometime ago, I noticed the "replace battery" indicator light on this unit was on. But it is no longer on. So I judged this is the best course of action. At least this UPS hasn't randomly failed before...
    • main vol is being pumped by TP1, backed by TP3.
    • TP2 remains off.
    • The annular volumes are isolated for now while we figure out what's up with TP2.
    • The pressure went up to ~1 mtorr (c.f. ~600utorr that is the nominal value with the stuck RV2) during the whole episode but is coming back down now.
  4. Steve seems to have taken the reliability of the vacuum system with him.

Details:

Around 7pm, the UPS at the vacuum rack seems to have failed. Don't ask me why I decided to check the vacuum screen 10 mins after the failure happened, but the point is, this was a silent failure so the protocols need to be looked into.

Going to the rack, I saw (unsurprisingly) that the 120V UPS was off. 

  • Pushed the power on button - the LCD screen would briefly light up, say the line voltage was 120 V, and then turned itself off. Not great.
  • I traced the power connection to the UPS itself to a power strip under the rack - then I moved the plug from one port to another. Now the UPS stays on. okay...
  • but after ~3 mins while I'm hunting for a VGA cable, I hear an incessant beeping. The UPS display has the "Fault" indicator lit up. 
  • I decided to shift everything back to the old UPS. After the change was made, I was able to boot up the c1vac machine again, and began the recovery process.
  • When I tried to start TP2, the drypump was unusually noisy, and I noticed PTP2 bottomed out at ~500 torr (yes torr). So clearly something is not right here. This pump supposedly had its tip-seal replaced by Jordan just 3 months ago. This is not a normal lifetime for the tip seal - we need to investigate more in detail what's going on here...
  • Decided that an acceptable config is to pump the main volume (so that we can continue working on other parts of the IFO). The annuli are all <10mtorr and holding, so that's just fine I think.

Questions:

  1. Are the failures of TP2 drypump and UPS related? Or coincidence? Who is the chicken and who is the egg?
  2. What's up with the short tip seal lifetime?
  3. Why did all of this happen without any of our systems catching it and sending an alert??? I have left the UPS connected to the USB/ethernet interface in case anyone wants to remotely debug this.

For now, I think this is a safe state to leave the system in. Unless I hear otherwise, I will leave it so - I will be in the lab another hour tonight (~10pm).

Some photos and a screen-cap of the Vac medm screen attached.

Attachment 1: rackBeforenAfter.pdf
rackBeforenAfter.pdf
Attachment 2: IMG_0008.jpg
IMG_0008.jpg
Attachment 3: IMG_0009.jpg
IMG_0009.jpg
Attachment 4: vacStatus.png
vacStatus.png
  15720   Wed Dec 9 16:22:57 2020 gautamUpdateSUSYet another round of Sat. Box. switcharoo

As discussed at the meeting, I decided to effect a satellite box swap for the misbehaving MC1 unit. I looked back at the summary pages Vmon for the SRM channels, and found that in the last month or so, there wasn't any significant evidence of glitchiness. So I decided to effect that swap at ~4pm today. The sequence of steps was:

  • SRM and MC1 watchdogs were disabled.
  • Unplugged the two satellite boxes from the vacuum flanges.
  • For the record: S/N 102 was installed at MC1, and S/N 104 was installed at SRM. Both were de-lidded, supposedly to mitigate the horrible thermal environment a bit. S/N 104 was the one Koji repaired in Aug 2019 (the serial number isn't visible or noted there, but only one box has jumper wires and Koji's photos show the same jumper wires). In June 2020, I found that the repaired box was glitching again, which is when I swapped it for S/N 102.
  • After swapping the two units, I re-enabled the local damping on both optics, and was able to re-lock the IMC no issues.

One thing I was reminded of is that the motion of the MC1 optic by controlling the bias sliders is highly cross-coupled in pitch and yaw, it is almost diagonal. If this is true for the fast actuation path too, that's not great. I didn't check it just now.

While I was working on this, I took the opportunity to also check the functionality of the RF path of the IMC WFS. Both WFS heads seem to now respond to angular motion of the IMC mirror - I once again dithered MC2 and looked at the demodulated signals, and see variation at the dither frequency, see Attachment #1. However, the signals seem highly polluted with strong 60 Hz and harmonics, see the zoomed-in time domain trace in Attachment #2. This should be fixed. Also, the WFS loop needs some re-tuning. In the current config, it actually makes the MC2T RIN worse, see Attachment #3 (reference traces are with WFS loop enabled, live traces are with the loop disabled - sorry for the confusing notation, I overwrote the patched version of DTT that I got from Erik that allows the user legend feature, working on getting that back).

Quote:

The MC1 suspension has begun to show evidence of glitches again, from Friday/Saturday. You can look at the suspension Vmon tab a few days ago and see that the excess fuzz in the Vmon was not there before. The extra motion is also clearly evident on the MCREFL spot. I noticed this on Saturday evening as I was trying to recover the IMC locking, but I thought it might be Millikan so I didn't look into it further. Usually this is symptomatic of some Satellite box issues. I am not going to attempt to debug this anymore.

Attachment 1: WFS2.png
WFS2.png
Attachment 2: WFS_lineNoise.png
WFS_lineNoise.png
Attachment 3: WFSchar.pdf
WFSchar.pdf
  15719   Wed Dec 9 15:37:48 2020 gautamUpdateCDSRFM switch IP addr reset

I suspect what happened here is that the IP didn't get updated when we went from the 131.215.113.xxx system to 192.168.113.xxx system. I fixed it now and can access the web interface. This system is now ready for remote debugging (from inside the martian network obviously). The IP is 192.168.113.90.

Managed to pull this operation off without crashing the RFM network, phew.

BTW, a windows laptop that used to be in the VEA (I last remember it being on the table near MC2 which was cleared sometime to hold the spare suspensions) is missing. Anyone know where this is ?

Attachment 1: Screenshot_2020-12-09_15-39-20.png
Screenshot_2020-12-09_15-39-20.png
Attachment 2: Screenshot_2020-12-09_15-46-46.png
Screenshot_2020-12-09_15-46-46.png
  15718   Wed Dec 9 12:02:04 2020 gautamUpdateLSCPOX locking still unsatisfactory

Continuting the IFO recovery - I am unable to recover similar levels of TRX RIN as I had before. Attachment #1 shows that the TRX RIN is ~4x higher in RMS than TRY RIN (the latter is commensurate with what we had previously). The excess is dominated by some low frequency (~1 Hz) fluctuations. The coherence structure is confusing - why is TRY RIN coherent with IMC transmission at ~2 Hz but not TRX? But anyways, doesn't look like its intensity fluctuations on the incident light (unsurprisingly, since the TRY RIN was okay). I thought it may be because of insufficient low-frequency loop gain - but the loop shape is the same for TRX and TRY. I confirmed that the loop UGF is similar now (red trace in Attachment #2) as it was ~1 month ago (black trace in Attachment #2). Seismometers don't suggest excess motion at 1 Hz. I don't think the modulation depth at 11 MHz is to blame either. As I showed earlier, the spectrum of the error point is comparable now as it was previously.

What am I missing?

Attachment 1: armRIN.pdf
armRIN.pdf
Attachment 2: POX_OLTF.pdf
POX_OLTF.pdf
  15717   Wed Dec 9 11:54:11 2020 gautamUpdateOptical LeversITMX HeNe replaced

The ITMX Oplev (installed in March 2019) was near end of life judging by the SUM channel (see Attachment #1). I replaced it yesterday evening with a new HeNe head. Output power was ~3.25 mW. The head was labelled appropriately and the Oplev spot was recentered on its QPD. The lifetime of ~20 months is short but recall that this HeNe had already been employed as a fiber illuminator at EX and so maybe this is okay.

Loop UGFs and stability margins seem acceptable to me, see Attachment #2-#3.

Attachment 1: OLtrend_old_ndscope.png
OLtrend_old_ndscope.png
Attachment 2: ITMX_OL_P.pdf
ITMX_OL_P.pdf
Attachment 3: ITMX_OL_Y.pdf
ITMX_OL_Y.pdf
  15716   Tue Dec 8 15:07:13 2020 gautamUpdateComputer Scripts / Programsndscope updated

I updated the ndscope on rossa to a bleeding edge version (0.7.9+dev0) which has many of the fixes I've requested in recent times (e.g. direct PDF export, see Attachment #1). As usual if you find issue, report it on the issue tracker. The basic functionality for looking at signals seems to be okay so this shouldn't adversely impact locking efforts.


In hindsight - I decided to roll-back to 0.7.9, and have the bleeding edge as a separate binary. So if you call ndscope from the command line, you should still get 0.7.9 and not the bleeding edge.

Attachment 1: test.pdf
test.pdf
  15715   Mon Dec 7 22:54:30 2020 gautamUpdateLSCModulation depth measurement

Summary:

I measured the modulation depth at 11 MHz andf 55 MHz using an optical beat + PLL setup. Both numbers are ~0.2 rad, which is consistent with previous numbers. More careful analysis forthcoming, but I think this supports my claim that the optical gain for the PDH locking loops should not have decreased.

Details:

  • For this measurement, I closed the PSL shutter between ~4pm and ~9pm local time. 
  • The photodiode used was the NF1611, which I assumed has a flat response in the 1-200 MHz band, and so did not apply any correction/calibration.
Attachment 1: modDepth.pdf
modDepth.pdf
  15714   Mon Dec 7 14:32:02 2020 gautamUpdateLSCNew demod phases for POX/POY locking

In favor of keeping the same servo gains, I tuned the digital demod phases for the POX and POY photodiode signals to put as much of the PDH error signal in the _I quadrature as possible. The changes are summarized below:

POX / POY demod phases
PD Old demod phase [deg] New demod phase [deg]
POX11 79.5 -75.5
POY11 -106.0 116.0

The old locking settings seem to work fine again. This setting isn't set by the ifoconfigure scripts when they do the burt restore - do we want it to be?

Attachments #1 and #2 show some spectra and TFs for the POX/POY loops. In Attachment #2, the reference traces are from the past, while the live traces are from today. In fact, to have the same UGF as the reference traces (from ~1 year ago), I had to also raise the digital servo loop gain by ~20%. Not sure if this can be put down to a lower modulation depth - at least, at the output on the freq ref box, I measured the same output power (at the 0dB variable attenuator gain setting we nominally run in) before and after the changes. But I haven't done an optical measurement of the modulation depth yet. There is also a hint of lesser phase available at ~100 Hz now compared to a year ago.

Attachment 1: POX_POY_OLTF.pdf
POX_POY_OLTF.pdf
Attachment 2: POX_POY_spectra.pdf
POX_POY_spectra.pdf
  15713   Mon Dec 7 12:38:51 2020 gautamUpdateIOOIMC loop char

Summary:

There seems to be significant phase loss in the TTFSS path, which is limiting the IMC OLTF to <100 kHz. 

Details:

See Attachment #1 and #2. The former shows the phase loss, while the latter is just to confirm that the optical gain of the error point is roughly the same, since I noticed this after working on and replacing the RF frequency distribution unit. Unfortunately there have been many other changes also (e.g. the work that Rana and Koji did at the IMC rack, swapping of backplane controls etc etc - maybe they have an OLTF measurement from the time they were working?) so I don't know which is to blame. Off the top of my head, I don't see how the RF source can change the phase lag of the IMC servo at 100 kHz. The only part of the IMC RF chain that I touched was the short cable inside the unit that routes the output of the Wenzel source to the front panel SMA feedthrough. I confirmed with a power meter that the power level of the 29.5 MHz signal at that point is the same before and after my work.

The time domain demod monitor point signals appear somewhat noisier in todays measurement compared to some old data I had from 2018, but I think this isn't significant. Once the SR785 becomes available, I will measure the error point spectrum as well to confirm. One thing I noticed was that like many of our 1U/2U chassis units, the feedthrough returns are shorted to the chassis on the RF source box (and hence presumably also to the rack). The design doc for this box makes many statements about the precautions taken to avoid this, but stops short of saying if the desired behavior was realized, and I can't find anything about it in the elog. Can someone confirm that the shields of all the connectors on the box were ever properly isolated? My suspicion is that the shorting is happening where the all-metal N-feedthroughs touch the drilled surfaces on the front panel - while the front and back surfaces of the panel are insulating, the machined surfaces are not.

This is an unacceptable state but no clear ideas of how to troubleshoot quickly (without going piece by piece into the IMC servo chain) occur to me. I still don't understand how the freq source work could have resulted in this problem but I'm probably overlooking something basic. I'm also wondering why the differential receiving at the TTFSS error point did not require a gain adjustment of the IMC servo? Shouldn't the differential-receiving-single-ended-sending have resulted in an overall x0.5 gain?


Update 8 Dec 1200: To test the hypothesis, I bypassed the SR560 based differential receiving and restored the original config. I am then able to run with the original gain settings, and you see in Attachment #4 that the IMC OLTF UGF is back above 100 kHz. It is still a little lower than it was in June 2019, not sure why. There must be some saturation issues somewhere in the signal chain because I cannot preserve the differential receiving and retain 100 kHz UGF, either by raising the "VCO gain" on the MC servo board, setting the SR560 to G=2, or raising the "Common Gain Adjust" on the FSS box by 6 dB. I don't have a good explanation for why this worked for some weeks and failed now - maybe some issue with the SR560? We don't have many working units so I didn't try switching it.

So either there is a whole mess of lines or the frequency noise suppression is limited. Sigh.

Attachment 1: OLTFcomparison.pdf
OLTFcomparison.pdf
Attachment 2: demodMons.pdf
demodMons.pdf
Attachment 3: OLTFcomparison.pdf
OLTFcomparison.pdf
  15712   Mon Dec 7 11:25:31 2020 gautamUpdateSUSMC1 suspension glitchy again

The MC1 suspension has begun to show evidence of glitches again, from Friday/Saturday. You can look at the suspension Vmon tab a few days ago and see that the excess fuzz in the Vmon was not there before. The extra motion is also clearly evident on the MCREFL spot. I noticed this on Saturday evening as I was trying to recover the IMC locking, but I thought it might be Millikan so I didn't look into it further. Usually this is symptomatic of some Satellite box issues. I am not going to attempt to debug this anymore.

  15711   Sat Dec 5 20:44:35 2020 gautamUpdateASCFreq Gen Box re-installed

This work is now complete. The box was characterized and re-installed in 1X2. I am able to (briefly) lock the IMC and see PDH fringes in POX and POY so the lowest order checks pass.

Even though I did not deliberately change anything in the 29.5 MHz path, and I confirmed that the level at the output is the expected 13 dBm, I had to lower then IN1 gain of the IMC servo by 2dB to have a stable lock - should confirm if this is indeed due to higher optical gain at the IMC error point, or some electrical funkiness. I'm not delving into a detailed loop characterization today - but since my work involved all elements in the RF modulation chain, some detailed characterization of all the locking loops should be done - I will do this in the coming week.

After tweaking the servo gains for the POX/POY loops, I am able to realize the single arm locks as well (though I haven't dont the characterization of the loops yet).

I'm leaving the PSL shutter open, and allowing the IMC autolocker to run. The WFS loops remain disabled for now until I have a chance to check the RF path as well.


Unrelated to this work: Koji's swapping back of the backplane cards seems to have fixed the WFS2 issue - I now see the expected DC readbacks. I didn't check the RF readbacks tonight.

Update 7 Dec 2020 1 pm: A ZHL-2 with heat sink attached and a 11.06 MHz Wenzel source were removed from the box as part of this work (the former was no longer required and the latter wasn't being used at all). They have been stored in the RF electronics cabinet along the east arm.

Attachment 1: IFOverview.png
IFOverview.png
Attachment 2: IMG_0004.jpg
IMG_0004.jpg
Attachment 3: IMG_9007.jpg
IMG_9007.jpg
Attachment 4: IMG_0003.jpg
IMG_0003.jpg
Attachment 5: schematicLayout.pdf
schematicLayout.pdf
Attachment 6: EOMpath_postMod.pdf
EOMpath_postMod.pdf
  15710   Fri Dec 4 22:41:56 2020 gautamUpdateASCFreq Gen Box revamp

This turned out to be a much more involved project than I expected. The layout is complete now, but I found several potentially damaged sections of cabling (the stiff cables don't have proper strain relief near the connectors). I will make fresh cables tomorrow before re-installing the unit in the rack. Several changes have been made to the layout so I will post more complete details after characterization and testing.

I was poring over minicircuits datasheets today, and I learned that the minicircuits bandpass filters (SBP10.7 and SBP60) are not bi-directional! The datasheet clearly indicates that the Male SMA connector is the input and the Female SMA connector is the output. Almost all the filters were installed the other way around 😱 . I'll install them the right way around now.

  15709   Fri Dec 4 19:23:40 2020 KojiUpdateElectronicsAA/AI board testing ongoing

I have the setup built for the AA/AI board testing around the PD testing area. Please let me leave it like that for a week or so.

12/4 TF Tested 5 PCBs
12/6 TF Tested 19 PCBs (12min/PCB) - found 1 failure (S2001479 CH1) -> Fixed 12/11
12/8 TF Tested 16 PCBs (12min/PCB)
       PSD Tested 4 PCBs (11min/PCB)
12/11 TF Tested 10 PCBs + 1 fixed channel (All channels checked)
       PSD Tested 10 PCBs (11min/PCB)
12/14 PSD Tested 4 PCBs (6.5min/PCB) fixed noise issue of 2 ch, TF issue of 1 ch
12/15 PSD Tested 32 PCBs (6.5min/PCB) fixed noise issue of 1ch
Temp dependence measurement
Crosstalk measurement
 

 

  15708   Fri Dec 4 15:58:22 2020 KojiUpdateIOOWFS2 broken

I checked the backplane connection for IMC WFS2  and found that the cables for IMC WFS2 and the IMC demod were swapped during my IMC noise hunting activities. I reverted it just now.

But we need to check if this damaged anything such as the WFS2 head, the WFS2 demod, etc, once the IMC locking is back.

  15707   Fri Dec 4 03:02:40 2020 KojiUpdateASCElectrical LO signal for AS WFS

1. That's true. But we are already in that regime with the Var attn at 0dB, aren't we? We can reduce the input to the amp by 1-2dBm sacrificing the EOM out by that amount (we can compensate this for the demo out by removing the 1dB attn).

2. Not 100% sure but one possible explanation is that we wanted to keep the Marconi output large (or as large as possible) to keep the SNR between the signal and the noise of the driver in Marconi. The attenuator is less noisy compared to the driver noise.

3. My guess is that theoretically we were supposed to have 13dBm input and 20dBm output in design. However, the actual input was as such.  We can restore it to the 13dBm input.

  15706   Thu Dec 3 21:44:49 2020 gautamUpdateASCElectrical LO signal for AS WFS

I'm open to either approach. If the full replacement requires a lot of machining, maybe I will stick to just the 55 MHz line. But if only a couple of new holes are required, it might be advantageous to do the revamp while we have the box out? What do you think?

BTW, now that I look more closely at the RF chain, I have several questions:

  1. The 1 dB compression power of the ZHL-2 amplifiers is ~29 dBm, and we are driving it at that level. Is this okay? I thought we always want to be several dBm away from the 1dBm compression point?
  2. Why do we have an attenuator between the Marconi input and the first ZHL-2 amplifier? Can't we just set the Marconi to output 8 or 9 dBm?
  3. The Wenzel frequency multiplier is rated to have 13dBm input and 20 dBm output. We operate it with 12 dBm input and 19 dBm output. Why throw away 1 dBm?

I guess it is feasible to have +17 dBm of 55 MHz signal to plug into the Quad Demod chassis - e.g. drive the 55 MHz input with 20 dBm, pick off 3dBm to the front panel for ASC. Then we can even have several "spare" 55 MHz outputs and still satisfy the 9 dBm input that the ZHL-2 in the 55 MHz chain wants (though again, isn't this dangerously close to the 1dB compression point?). The design doc claims to have done some Optickle modeling, so I guess there isn't really any issue? 

Quote:

Are you going to full replacement of the 55MHz system? Or just remove the 7dBm and then implement the proposed modification for the 55MHz line?

  15705   Thu Dec 3 21:14:38 2020 KojiUpdateASCElectrical LO signal for AS WFS

Let's use RG405 for better shielding. It is not too stiff. The bending  (just once) does not break the cable.

Are you going to full replacement of the 55MHz system? Or just remove the 7dBm and then implement the proposed modification for the 55MHz line?

  15704   Thu Dec 3 20:38:46 2020 gautamUpdateASCElectrical LO signal for AS WFS

I removed the Frequency Generation box from the 1X2 rack. For the time being, the PSL shutter is closed, since none of the cavities can be locked without the RF modulation source anyways.

Prior to removal, I did the following:

  1. Measured powers at each port on the front panel 
    • Gigatronix power meter was used, which has a maximum power rating of 20dBm, so for the EOM drive outputs which we operate closer to 25-27 dBm, I used a 20 dBm coupler to make the measurement.
    • Attachment #1 summarizes my findings - there doesn't seem to be anything majorly wrong, except that for the 11 MHz EOM drive channel, the "7" setting on the variable attenuator doesn't seem to work. 
    • We can probably get a replacement from MiniCircuits, but since we operate at 0dBm variable attenuation nominally, maybe we don't need to futz around with this.
  2. Measured the relative phasing between the 11 MHz and 55 MHz signals using an oscilloscope.
    • I measured the relative phase for the EOM drive channels, and also the demod channels.
    • The scope can accept a maximum of 5V RMS signal with 50ohm input impedance. So once again, I couldn't make a direct measurement at the nominal setting for the EOM drive channel. Instead, I used the variable attenuator to set the signal amplitude to ~2V RMS. 
    • I will upload the time-domain plots later. But we now have a record of the relative phasing that we can try and reproduce after making modifications. FWIW, my measured phase difference of 139 degrees is reasonably consistent with Koji's inferred from the modulation spectrum.

One thing I noticed was that we're using very stiff coax cabling (RG405) inside this box? Do we need to stick with this option? Or can we use the more flexible RG316? I guess RG405 is lower loss, so it's better. I can't actually find any measurement of the shielding performance in my quick google searching but I think the claim on the call yesterday was that RG405 with its solder soaked braids offer superior shielding.

Before doing any modification you should check how much the distributed powers are at the ports.
Also your modification will change the relative phase between 11MHz and 55MHz.
Can you characterize how much phase difference you have between them, maybe using the modulation of the main marconi? And you might want to adjust it to keep the previous value (or any new value) after the modification by adding a cable inside?

Attachment 1: RF_Frequency_Source.pdf
RF_Frequency_Source.pdf
Attachment 2: demodPath.pdf
demodPath.pdf
Attachment 3: EOMpath.pdf
EOMpath.pdf
  15703   Thu Dec 3 14:53:58 2020 JonUpdateVACReplacing pressure gauges

Update to the gauge replacement plan (15692), based on Jordan's walk-through today. He confirmed:

  • All of the gauges being replaced are mounted via 2.75" ConFlat flange. The new FRGs have the same footprint, so no adapters are required.
  • The longest Agilent cable (50 ft) will NOT reach the CCMC location. The fifth FRG will have to be installed somewhere closer to the X-end.

Based on this info (and also info from Gautam that the PAN gauge is still working), I've updated the plan as follows. In summary, I now propose we install the fifth FRG in the TP1 foreline (PTP1 location) and leave P2 and P3 where they are, as they are no longer needed elsewhere. Any comments on this plan? I plan to order all the necessary gaskets, blanks, etc. tomorrow.

Volume Sensor Location Status Proposed Action
Main P1a functioning leave
Main P1b local readback only leave
Main CC1 dead replace with FRG
Main CCMC dead remove; cap with 2.75" CF blank
Pumpspool PTP1 dead replace with FRG
Pumpspool P2 functioning leave
Pumpspool CC2 dead replace with FRG
Pumpspool PTP2 functioning leave
Pumpspool P3 functioning leave
Pumpspool CC3 dead replace with FRG
Pumpspool PTP3 functioning leave
Pumpspool PRP functioning leave
RGA P4 functioning leave
RGA CC4 dead replace with FRG
RGA IG1 dead remove; cap with 2.75" CF blank
Annuli PAN functioning leave
Annuli PASE functioning leave
Annuli PASV functioning leave
Annuli PABS functioning leave
Annuli PAEV functioning leave
Annuli PAEE functioning leave
  15702   Thu Dec 3 13:55:52 2020 KojiUpdateASCElectrical LO signal for AS WFS

I got a bit confused by your description.

The demod board claims that the nominal power at each LO port is 10dBm. So we want to give at least 16dBm to the (external?) 4way power splitter, but we only have 15dBm. As you said, the actual LO power reaching the FET mixier (PE4140) is the level of ~20dBm. But you said the requirement for the mixer is -7dBm. So are you proposing to reduce the LO level (slightly) than the LIGO recommendation because the minimum for PE4140 is -7dBm?
If that's the message, then I can say "yes". We supply 8~9dBm to the LO ports instead of 10dBm. I suppose the mixers don't care about this level of reduction.

Looking at my original post [40m ELOG 11817], the necessary modification is much larger than you have indicated in your post (as yours is the modification of my modification plan.)
If you do your modification you have to deal with the components rearrangement in the chassis. I think you can still accomplish it as you are going to remove an amplifier and gain the space from it.

The main RF line still has 5dBm Attn. How about to insert another 3dB power splitter there and create a spare 55MHz port for the future use?

Before doing any modification you should check how much the distributed powers are at the ports.
Also your modification will change the relative phase between 11MHz and 55MHz.
Can you characterize how much phase difference you have between them, maybe using the modulation of the main marconi? And you might want to adjust it to keep the previous value (or any new value) after the modification by adding a cable inside?

 

  15700   Thu Dec 3 11:02:35 2020 ranaUpdateElectronicsElectrical LO signal for AS WFS

looks good to me.

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

  15699   Thu Dec 3 10:46:39 2020 gautamUpdateElectronicsDC power strip requirements

Since we will have several new 1U / 2U aLIGO style electronics chassis installed in the racks, it is desirable to have a more compact power distribution solution than the fusable terminal blocks we use currently. 

  • The power strips come in 2 varieties, 18 V and 24 V. The difference is in the Dsub connector that is used - the 18 V variant has 3 pins / 3 sockets, while the 24V version uses a hybrid of 2 pins / 1 socket (and the mirror on the mating connector).
  • Each strip can accommodate 24 individual chassis. It is unlikely that we will have >24 chassis in any collection of racks, so per area (e.g. EX/EY/IOO/SUS), one each of the 18V and 24V strips should be sufficient. We can even migrate our Acromag chassis to be powered via these strips.
  • Details about the power strip may be found here.

I did a quick walkaround of the lab and the electronics rack today. I estimate that we will need 5 units of the 24 V and 5 units of the 18 V power strips. Each end will need 1 each of 18 V and 24 V strips. The 1Y1/1Y2/1Y3 (LSC/OMC/BHD sus) area will be served by 1 each 18 V and 24 V. The 1X1/1X2 (IOO) area will be served by 1 each 18 V and 24 V. The 1X5/1X6 (SUS Shadow sensor / Coil driver) area will be served by 1 each of 18 V and 24 V.  So I think we should get 7 pcs of each to have 2 spares.

Most of the chassis which will be installed in large numbers (AA, AI, whitening) supports 24V DC input. A few units, like the WFS interface head, OMC driver, OMC QPD interface, require 18V. It is not so clear what the input voltage for the Satellite box and Coil Drivers should be. For the former, an unregulated tap-off of the supply voltage is used to power the LT1021 reference and a transistor that is used to generate the LED drive current for the OSEMs. For the latter, the OPA544 high current opamp used to drive the coil current has its supply rails powered by again, an unregulated tap-off of the supply voltage. Doesn't seem like a great idea to drive any ICs with the unregulated switching supply voltage from a noise point of view, particularly given the recent experience with the HV coil driver testing and the PSRR, but I think it's a bit late in the game to do anything about this. The datasheet specs ~50 dB of PSRR on the negative rail, but we have a couple of decoupling caps close to the IC and this IC is itself in a feedback loop with the low noise AD8671 IC so maybe this won't be much of an issue.

For the purposes of this discussion, I think both Satellite Amp and Coil Driver chassis can be driven with +/- 24 V DC.


On a side note - after the upgrade will the "Satellite Amplifiers" be in the racks, and not close to the flange as they currently are? Or are we gonna have some mini racks next to the chambers? Not sure what the config is at the sites, and if the circuits are designed to drive long cables.

  15698   Thu Dec 3 10:33:00 2020 gautamUpdateVACTrippLite UPS delivered

The latest greatest UPS has been delivered. I will move it to near the vacuum rack in its packaging for storage. It weighs >100lbs so care will have to be taken when installing - can the rack even support this?

Attachment 1: DFDD4F39-3F8A-439D-888D-7C0CE2E030CF.jpeg
DFDD4F39-3F8A-439D-888D-7C0CE2E030CF.jpeg
  15697   Wed Dec 2 23:07:19 2020 gautamUpdateASCElectrical LO signal for AS WFS

I'm thinking of making some modifications to the RF distribution box in 1X2, so as to have an extra 55 MHz pickoff. Koji already proposed some improvements to the layout in 2015. I've marked up his "Possible Improvement" page of the document in Attachment #1, with my proposed modifications. I believe it will be possible to get 15-16 dBm of signal into a 4 way RF splitter in the quad demod chassis. With the insertion loss of the splitter, we can have 9-10 dBm of LO reaching each demod board, which will then be boosted to +20 dBm by the Teledyne on board. The PE4140 mixer claims to require only -7 dBm of LO signal. So we have quite a bit of headroom here - as long as we limit the RF signal to 0dBm (=0.5 Vpp from the LMH6431 opamp at 55 MHz, we shouldn't be having a much larger signal anyways), we should be just fine with 15 dBm of LO power (which is what we will have after the division into the I and Q paths, and nominal insertion losses in the transmission path). These numbers may be slight overestimates given the possible degradation of the RF amps over the last 10 years, but shouldn't be a show-stopper.

Do the RF electronics experts agree with my assessment? If so, I will start working on these mods tomorrow. Technically, the splitter can be added outside the box, but it may be neater if we package it inside the box. 

Attachment 1: RF_Frequency_Source.pdf
RF_Frequency_Source.pdf
  15696   Wed Dec 2 18:35:31 2020 gautamUpdateDetCharSummary page revival

The summary pages were in a sad state of disrepair - the daily jobs haven't been running for > 1 month. I only noticed today because Jordan wanted to look at some vacuum trends and I thought summary pages is nice for long term lookback. I rebooted it just now, seems to be running. @Tega, maybe you want to set up some kind of scripted health check that also sends an alert.

  15695   Wed Dec 2 17:54:03 2020 gautamUpdateCDSFE reboot

As discussed at the meeting, I commenced the recovery of the CDS status at 1750 local time.

  • Started by attempting to just soft-restart the c1rfm model and see if that fixes the issue. It didn't and what's more, took down the c1sus machine.
  • So hard reboots of the vertex machines was required. c1iscey also crashed. I was able to keep the EX machine up, but I soft-stopped all the RT models on it.
  • All systems were recovered by 1815. For anyone checking, the DC light on the c1oaf model is red - this is a "known" issue and requires a model restart, but i don't want to get into that now and it doesn't disrupt normal operation.

Single arm POX/POY locking was checked, but not much more. Our IMC WFS are still out of service so I hand aligned the IMC a bit, IMC REFL DC went from ~0.3 to ~0.12, which is the usual nominal level.

  15694   Wed Dec 2 15:27:06 2020 gautamSummaryComputer Scripts / ProgramsTC200 python driver

FYI, there is this. Seems pretty well maintained, and so might be more useful in the long run. The available catalog of instruments is quite impressive - TC200 temp controller and SRS345 func gen are included and are things we use in the lab. maybe you can make a pull request to add MDT694B (there is some nice API already built I think). We should also put our netgpibdata stuff and the vacuum gauge control (basically everything that isn't rtcds) on there (unless there is some intellectual property rights issues that the Caltech lawyers have to sort out).

Quote:

Given the similarities between the MDT694B (single channel piezo controller) and TC200 (temperature controller) serial interfaces, I added the pyserial driver here

*Warning* this first version of the driver remains untested

  15693   Wed Dec 2 12:35:31 2020 PacoSummaryComputer Scripts / ProgramsTC200 python driver

Given the similarities between the MDT694B (single channel piezo controller) and TC200 (temperature controller) serial interfaces, I added the pyserial driver here

*Warning* this first version of the driver remains untested

  15692   Wed Dec 2 12:27:49 2020 JonUpdateVACReplacing pressure gauges

Now that the new Agilent full-range gauges (FRGs) have been received, I'm putting together an installation plan. Since my last planning note in Sept. (ELOG 15577), two more gauges appear to be malfunctioning: CC2 and PAN. Those are taken into account, as well. Below are the proposed changes for all the sensors in the system.

In summary:

  • Four of the FRGs will replace CC1/2/3/4.
  • The fifth FRG will replace CCMC if the 15.6 m cable (the longest available) will reach that location.
  • P2 and P3 will be moved to replace PTP1 and PAN, as they will be redundant once the new FRGs are installed.

Required hardware:

  • 3x CF 2.75" blanks
  • 10x CF 2.75" gaskets
  • Bolts and nut plates
Volume Sensor Location Status Proposed Action
Main P1a functioning leave
Main P1b local readback only leave
Main CC1 dead replace with FRG
Main CCMC dead replace with FRG*
Pumpspool PTP1 dead replace with P2
Pumpspool P2 functioning replace with 2.75" CF blank
Pumpspool CC2 intermittent replace with FRG
Pumpspool PTP2 functioning leave
Pumpspool P3 functioning replace with 2.75" CF blank
Pumpspool CC3 dead replace with FRG
Pumpspool PTP3 functioning leave
Pumpspool PRP functioning leave
RGA P4 functioning leave
RGA CC4 dead replace with FRG
RGA IG1 dead replace with 2.75" CF blank
Annuli PAN intermittent replace with P3
Annuli PASE functioning leave
Annuli PASV functioning leave
Annuli PABS functioning leave
Annuli PAEV functioning leave
Annuli PAEE functioning leave

 

Quote:

For replacements, I recommend we consider the Agilent FRG-700 Pirani Inverted Magnetron Gauge. It uses dual sensing techniques to cover a broad pressure range from 3e-9 torr to atmosphere in a single unit. Although these are more expensive, I think we would net save money by not having to purchase two separate gauges (Pirani + hot/cold cathode) for each location. It would also simplify the digital controls and interlocking to have a streamlined set of pressure readbacks.

For controllers, there are two options with either serial RS232/485 or Ethernet outputs. We probably want the Agilent XGS-600, as it can handle all the gauges in our system (up to 12) in a single controller and no new software development is needed to interface it with the slow controls.

 

  15691   Sat Nov 28 21:44:53 2020 ranaUpdateASCPlanned mods for WFS head

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

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

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

  15690   Wed Nov 25 18:30:23 2020 gautamUpdateASCSome thoughts about AS WFS electronics

An 8 channel whitening chassis was prepared and tested. I measured:

  1. TF from input to output - there are 7 switchable stages (3 dB, 6 dB, 12 dB and 24 dB flat whitening gain, and 3 stages of 15:150 Hz z:p whitening). I enabled one at a time and measured the TF. 
  2. Noise with input terminated.

In summary,

  1. All the TFs look good (I will post the plots later), except that the 3rd stage of whitening on both boards don't show the expected transfer function. The fact that it's there on both boards makes me suspect that the switching isn't happening correctly (I'm using a little breakout board). I'm inclined to not debug this because it's unlikely we will ever use 3 stages of 15:150 whitening for the AS WFS. 
  2. The noise measurement displayed huge (x1000 above the surrounding broadband noise floor) 60 Hz harmonics out to several kHz. My hypothesis is that this has to do with some bad grounding. I found that the circuit ground is shorted to the chassis via the shell of the 9pin and 15pin Dsub connectors (but the two D37 connector shields are isolated). This seems very wierd, idk what to make of this. Is this expected? Looking at the schematic, it would appear that the shields of the connectors are shorted to ground which seems like a bad idea. afaik, we are using the same connectors as on the chassis at the sites - is this a problem there too? Any thoughts
Quote:

Whitening chassis. Waiting for front panels to arrive, PCBs and interface board are in hand, stuffed and ready to go. A question here is how we want to control the whitening - it's going to be rather difficult to have fast switchable whitening. I think we can just fix the whitening state. Another option would be to control the whitening using Acromag BIO channels.

ELOG V3.1.3-