40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 315 of 337  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  15464   Thu Jul 9 17:12:52 2020 gautamUpdateBHDIn-air BHD

Summary:

We can probably learn something about the interferometer / top level BHD plan with an in-air BHD setup, even if the noise is bad. Here are some thoughts about how we would do it. 

LO delivery:

For this first attempt, we don't really care about the PRC filtering. So possible places to pick off an LO beam are:

LO beam pickoff options
Location Pros Cons
IP POS
  • Filtered by IMC
  • Medium level of invasiveness  
  • We lose the IP POS diagnostic, which is kind of useful nowadays given the drifty TTs.
  • Only few mW LO power available
PSL table IR beam currently going to green doubling setup
  • Least invasive w.r.t. normal IFO operation
  • Plenty of light (~100 mW) available. But how much can we safely couple into fiber?
  • Beam not filtered by IMC (although it is filtered by the PMC)
POX/POY
  • Since this beam is extracted from inside the PRC, probably enjoys the best filtering.
  • Possibly drifts a lot, so tricky to reliably couple into a fiber?
  • Maximally invasive w.r.t. regular IFO operations.

In all cases, I think the easiest option to actually route whatever beam we choose into a fiber, and then bring it over to whatever cavity we choose to use for an OMC. I'm assuming whatever phase control technique we end up using can cancel the fiber phase noise at relevant frequencies.

LO phase control

  • Stress the fiber? This will require us to purchase some custom hardware, and interface it to the CDS system.
  • PZT mirror? We should have sufficient hardware available to drive a PI style PZT mirror.

There is a question about the range, but I think these are the only two realistic options we can implement on a reasonable time scale.

OMC:

Again, there are a few options. Here are some pros and cons that come to my mind.

OMC cavity options
Option Pros Cons
Old copper OMC
  • Probably the simplest option in terms of the peripherals.
  • PZT driver recently verified to work
  • We can get the OMMT and DCPDs out as well.
  • Allows us to not compromise on the RF darm optical gain (not sure if locking will be as easy if we cut the power to the AS55 photodiode by 50-75%).
  • Requires a vent.
  • Probably not the most efficient use of the space on the AP table.
  • Filtering performance isn't quantified.
Spare PMC
  • Doesn't require a vent.
  • Compact footprint.
  • Need to build the cavity.
  • Need to check if the drive electronics from the old copper OMC can easily be interfaced with whatever PZT we use on this cavity.
  • Filtering performance kind of unknown?
Custom cavity with spare mirrors
  • Doesn't require a vent.
  • Probably no more difficult than the spare PMC option?
  • We need at least one actuatable mirror, so we'd need some PZT mounted optic + associated drive electronics.

If we can do a vent (we'd just need a single chamber open), I'd go for the option of getting the copper OMC out and using that. Attachment #1 shows the approximate sizes of the various components (OMMT, OMC cavity, DCPDs), while Attachment #2 shows a rough sketch of where things would go on the AP table, with the rectangles approximately to scale.

CDS:

I'd made a c1omc model sometime ago. Basically, I think we have sufficient ADC/DAC channels in the c1ioo machine for any of the options listed above - but using the copper OMC and associated peripherals would allow the easiest interfacing.

Criticisms/comments/thoughts please.

Attachment 1: OMCchamber.pdf
OMCchamber.pdf
Attachment 2: AP_Table_20180328.pdf
AP_Table_20180328.pdf
  15466   Fri Jul 10 01:25:28 2020 gautamUpdateLSCLocking notes

More tomorrow, but I tried the following tonight:

  1. Dither alignment for PRC / MICH seems to work when the PRFPMI is locked. Unfortunately, the correct settings for the arm cavity dither alignment loops continue to elude me.
  2. I tried some arm ASC loop characterization by stepping the error points of these loops - I saw some weird cross coupling between the loops that needs investigation.
  3. I'm unable to turn an integrator on for the "Common YAW" QPD loop - unclear why this is, but every time I attempt to engage said integrator, the lock is immediately blown. Needs some investigation of the signals.
  4. With the PRC / MICH angular DoFs aligned with the dither alignemnt, and the arm ASC loops hand tuned, I was able to get the darkest dark port I've seen. In terms of ASDC counts, it was ~ 200, which after undoing all the digital gains etc corresponds to ~100 uW of light. I think we can get a rough estimate of the contrast defect by accounting for (i) T_SRM, (ii) OMC pickoff fraction (iii) other losses between the BS dark port and the AP table (iv) 50/50 BS between AS55 and AS110 PD (the ASDC signal is derived from the former) and (v) the throughput of the 55 MHz sideband to the dark port, although there are many uncertainties. 
  15467   Fri Jul 10 10:37:30 2020 JordanUpdateGeneralPresence at 40m

I will be in the Clean and Bake lab today from 9am to 4pm

  15468   Fri Jul 10 15:26:28 2020 gautamUpdateLSCMC2 coils need DC balancing?

I was looking at some signals from last night, see Attachment #1.

  • It looks like as the DC control signal to the MC2 suspension increases, the MC transmission decreases.
    • I confirmed that the IMC REFL level doesn't correspondingly trend up, but didn't include it here for plot compactness, so I think the cavity length isn't being detuned.
    • So the problem is suggestive of some L2A coupling, and the MC2 coil actuators need to be balanced better at DC?
    • You can see from the IMC WFS control signals that the WFS servo is presumably trying to counteract this L2A action, but doesn't succeed, probably because the servo isn't tuned correctly.
    • This is a problem that is distinct from the drifting TT alignment. So it complicates the alignment situation.
    • Ideally, if the dither alignment servos could be made to work for the arm cavities when locked in the PRFPMI config, this wouldn't be so much of a problem, as the TTs would just adjust the beam pointing to match the cavity axes of the arms. But since I haven't managed to get that servo working yet...
  • But why should MC2 need such a large DC control signal ever?
    • In the PRFPMI lock, the CARM servo is supposed to match the laser frequency to the average length of the two arm cavities.
    • The MC2 suspension is used as a frequency actuator in order to realize this matching.
    • But, as you can see, the digital CARM control signal picks up a significant DC offset the deeper we go into the lock.
    • Can't we offload this DC signal to the laser crystal temperature servo? Is there going to be some weird interaction with the existing slow loop? Or is the idea itself flawed?

Attachment #2 shows some ASC metrics. My conclusion here is that running the PRCL and MICH dither alignment servos (former demodulating REFLDC and latter demodulating ASDC to get an error signal) that running the dither alignment servo and hand tuning the arm ASC loop offsets improves the mode matching to the IFO, because:

  1. The arm transmission increases.
  2. POPDC increases.
  3. ASDC decreases.

The REFLDC behavior needs a bit more interpretation I think, because if the IFO is overcoupled (as I claim it is), then better alignment would at some point actually result in REFLDC increasing. 

All the DC signals recorded by the fast system come from the backplane P2 connector of the PD interface boards. According to the schematic, these signals have a voltage gain of 2. The LSC photodiodes themselves have a nominal DC gain of 50 ohms. So, the conversion from power to digital counts is: 0.8 A/W * 50 V/A * 2 * 3276.8 cts/V * whtGain. Inverting, I get 3.8 uW/ct for a whitening gain of 1. This is power measured at the photodiode - optical losses upstream of the photodiode will have to be accounted for separately.

Assuming a modulation depth of 0.2, the 55 MHz sideband power should be ~20 mW. The Schnupp asymmetry is supposed to give us O(1) transmission of this field to the AS port. Then, the SRM will attenuate the field by a factor of 10, so we expect ~2 mW at the AS port. Let's assume 80 % throughput of this field to the AP table, and then there is a 50/50 beamsplitter dividing the light between the AS55 and AS110 photodiodes. So, we expect there to be ~700 uW of power in the TEM00 mode 55 MHz sideband field. This corresponds to 1600 cts according to the above calibration (the ASDC whitening gain is set to 18 dB). The fact that much smaller numbers were seen for ASDC indicates that (i) the schnupp asymmetry is not so perfectly tuned and the actual transmission of the sideband field to the dark port is smaller, or (ii) one or more optical splitting fractions assumed above is wrong. If the former is true, we can still probably infer the contrast defect if we can somehow get an accurate measurement of the sideband transmission to the dark port.

Attachment 1: MC2_balancing.png
MC2_balancing.png
Attachment 2: ASDC.png
ASDC.png
  15469   Sat Jul 11 00:10:22 2020 gautamUpdateComputersrossa: more developmental work

After some consultation with Erik von Reis at LHO, this workstation is progressing towards being usable for most commissioning tasks. DTT, awggui, foton, and MEDM are all now working well. The main limitation now comes from the fact that many of our python scripts are written for python2, and rossa doesn't have many dependencies installed for python2. I see no reason to build these dependencies on rossa for python2, we should not have to work with an unsupported language. But at the same time, I don't want to completely wipe all our python2 scripts, and make them python3, because this would involve a lot of tedious testing that I'm not prepared to undertake at the moment (the problem is compounded by the fact that pianosa does not have many dependencies installed for python3).

So what I have done in the interim is make python3 versions of the most important scripts I need to get the PRFPMI locking working - they are in the scripts directory and have the same names as their python2 counterparts, but have a 3 appended to their names. So when working on rossa, these are the scripts that are called. Eventually, after a lot more testing, we can depracate the old scripts. Currently, where applicable, the MEDM screens allow for either the python2 or python3 version of the script to be called.

Please, for the time being, do not try and install any new packages on rossa unless you are prepared to debug any problems caused and return the machine to a workable state. If you find some issue with a missing package on rossa, (i) make a note of it on the elog, and (ii) if possible, set up your own conda environment for testing and install dependencies to that environment only.

  15470   Sat Jul 11 18:24:30 2020 KojiUpdateLSCMC2 coils need DC balancing?

> Can't we offload this DC signal to the laser crystal temperature servo?
No. PSL already follows the MC length. So this offset is coming from the difference between the MC length and the CARM length.
What you can do is to offload the MC length to the CARM DC if this helps.

  15471   Sun Jul 12 02:42:01 2020 gautamUpdateLSCLocking (on rossa)

Main goals tonight were:

  1. Check if I can lock the interferometer by working on rossa - indeed, I could! It is much snappier than the ageing pianosa. The viewing angle of the CRT monitors from this corner isn't so good though.
  2. Measure step responses for the arm ASC loops to see if any insight can be gained into these loops. Analysis forthcoming...
Attachment 1: ASCsteps.png
ASCsteps.png
  15472   Sun Jul 12 22:40:35 2020 gautamUpdateElectronicsWFS characterization - old SURF report

After some hunting, I found this old SURF report with the WFS head measurements. The y-axes don't make much sense to me, and I can't find the actual data anywhere (her wiki page doesn't actually exist). So I think it's still unknown if these heads ever had the advertised transimpedance gain, or if the measured transimpedance of ~1kohm was what it always was.

  15473   Mon Jul 13 11:33:18 2020 ranaUpdateComputersrossa: more developmental work

I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?

Is it possible to just make a python2 conda environment on rossa? I would guess that its simple and won't interfere with the regular operation of that machine.

  15474   Mon Jul 13 11:36:08 2020 ranaUpdateLSCMC2 coils need DC balancing?
  1. if IMC REFL is not increasing, I don't think its a mis-alignment. Usually, REFL is a more sensitive indicator of alignment than TRANS since its usually near zero. Maybe the MC2 TRANS PD is not centered or doesn't have enough lens action.
  2. to reduce the DC load on MC2, you could have a slow releif drive the ETMs and DC and minimize LSC-MCL
  15475   Mon Jul 13 12:37:05 2020 gautamUpdateComputersrossa: more developmental work

In fact, all these utilities are now available in python3. There may be some bugs (e.g. this), but I've checked basic functionality and things look usable enough for development to proceed. While we can have a python2 env on rossa, I think it's unnecessary.

Quote:

I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?

  15476   Tue Jul 14 00:06:09 2020 gautamUpdateLSCLocking with POX for CARM

I tried using the POX_I error signal for the DC CARM_B path today a couple of times. Got to a point where the AO path could be engaged and the arm powers stabilized somewhat, but I couldn't turn the CARM_A path off without blowing the lock. Now the IMC has entered a temperemental state, so I'm abandoning efforts for tonight, but things to try tomorrow are:

  1. Check that the demod phase is set correctly
  2. With the CARM_B path engaged, measure some CARM OLTFs. Tonight, I was a bit over-optimistic I think, by expecting the scripted transition to take me all the way, but I think I'll have to fiddle around with the gains a bit.
  3. Check for offsets. The AO path should be AC coupled, but maybe the POX signal has some offset?

I have some data from a couple of days ago when the PRFPMI was locked as usual (CARM_B on REFL for both DC and AO paths), and the sensing lines were on, so I can measure the relative strength of the sensing lines in POX/REFL and get an estimate of what the correct digital gain should be.

The motivation here is to see if the sensing matrix looks any different with a modified locking scheme.

  15477   Tue Jul 14 01:55:03 2020 KojiUpdateLSCLocking with POX for CARM

The usual technique is that keeping the IFO locked with the old set of the signals and the relative gain/TF between the conventional and new signals are measured in-lock so that you can calibrate the new gain/demod-phase setting.

  15478   Tue Jul 14 09:04:53 2020 JordanUpdateGeneralPresence at 40m

I will be in the Clean and Bake Lab today from 9am to 4pm.

  15479   Tue Jul 14 15:29:25 2020 gautamUpdateBHDIn-air BHD - DCPD amplifier noise

For the first pass, it's probably easiest to use the existing DCPD amplifier. Looking at the gain and noise performance in Attachment #1, seems totally fine, the electronics noise will not be limiting if we have ~10mW of LO power. I assumed a transimpedance resistor of 1 kohm, and all other numbers as on the schematic (though who knows if the schematic is accurate). The noise should be measured to confirm that the box is performing as expected...

Attachment 1: DCPDamp.pdf
DCPDamp.pdf
  15480   Tue Jul 14 16:52:47 2020 gautamUpdateElectronicsCoil drivers for the test masses

Summary:

Koji and I had a discussion last Friday about the suspension electronics. I think there are still a few open questions - see Attachment #1. We should probably make a decision on these soon.

Other useful links:

  1. High-voltage coil driver circuit - D1900163
    • This board is ready to be fabricated and tested on the bench.
    • The way the connectors J2 and J3 are designed currently is meant to interface with the existing coil driver electronics.
    • Depending on the eventual coil driver we choose for the fast path, it may be benificial to change the signals on the connectors J2 and J3, to avoid the need for a custom interface board.
  2. HAM-A coil driver noise analysis.
    • The linked attachment evaluates the noise for the design value of the fast path series resistor, which is 1.2 kohms.
    • Iff we still have ambitions of measuring ponderomotive squeezing, we will need the resistance to be much higher, ~10 kohms (in the linked noise budget, only the Johnson noise of the series resistor is considered, but in reality, the OpAmp voltage and current noises also matter). 
    • This corresponds to a maximum current of 10V/10kohms = 100uA
    • Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).
    • So we may need a version of the fast coil driver that supports a low noise mode (with large series resistance) and a high-range mode (with lower series resistance for lock acquisition).
  3. You can follow the links to DCC entries for other parts from Attachment #1.
Attachment 1: coilDriverSchem.pdf
coilDriverSchem.pdf
  15481   Tue Jul 14 17:28:29 2020 gautamUpdateLSCLocking with POX for CARM

From Attachment #1, looks like the phasing and gain for CARM on POX11 is nearly the same as CARM of REFL11, which is probably why I was able to execute a partial transition last night. The response in POY11 is ~10 times greater than POX11, as expected - though the two photodiodes have similar RF transimpedance, there is a ZFL-500-HLN at the POY11 output. The actual numerical values are 2.5e10 cts/m for CARM-->REFL11_I, 2.6e10 cts/m for CARM-->POX11_I, and 3.2e11 cts/m for CARM-->POY11_I.

So I think I'll just have to fiddle around with the transition settings a little more tonight. 

One possible concern is that the POX and POY signals are digitized without preamplificatio, maybe this explains the larger uncertainty ellipse for the POX and POY photodiodes relative to the REFL11 photodiode? Maybe the high frequency noise is worse and is injecting junk in the AO path? I think it's valid to directly compare the POX and REFL spectra in Attachment #2, without correcting for any loops, because this signal is digitized from the LSC demodulator board output (not the preamplified one, which is what goes to the CM board, and hence, is suppressed by the CARM loop). Hard to be sure though, because while the heads are supposed to have similar transimpedance, and the POX photodiode has +12dB more whitening gain than REFL11, and I don't know what the relative light levels on these photodiodes are in lock.

Quote:

I have some data from a couple of days ago when the PRFPMI was locked as usual (CARM_B on REFL for both DC and AO paths), and the sensing lines were on, so I can measure the relative strength of the sensing lines in POX/REFL and get an estimate of what the correct digital gain should be

Attachment 1: PRFPMI_2020712sensMat.pdf
PRFPMI_2020712sensMat.pdf
Attachment 2: LSCerrSigs.pdf
LSCerrSigs.pdf
  15483   Wed Jul 15 19:11:40 2020 gautamUpdateBHDIn-air BHD - alignment into OMC

I forgot about the pointing - probably we will need another actuator to control the pointing of the AS beam onto the DCPDs. I found a few old PI PZTs (model number is S-320, which is a retired part), one is labelled broken but the others don't indicate a-priori that they are broken. I'll post a more detailed hardware survey later.

  Draft   Wed Jul 15 19:17:09 2020 gautamUpdateBHDIn-air BHD - alignment into OMC

You can activate all 3axis

 

  15485   Wed Jul 15 19:23:44 2020 gautamUpdateGeneralEmergency light on in control room

The emergency lamps above the exit sign on the NW entrance to the control room are on. I tried opening and closing the door, but it remains on. Probably nothing to worry about, but noting here anyway.

  15486   Wed Jul 15 19:51:51 2020 KojiUpdateGeneralEmergency light on in control room

It happened before too. Doesn't it say it has occasional self-testing or something?

  15487   Wed Jul 15 20:58:40 2020 gautamUpdateGeneralEmergency light on in control room

True - it is now not on anymore.

Quote:

It happened before too. Doesn't it say it has occasional self-testing or something?

  15488   Wed Jul 15 21:08:43 2020 gautamUpdateElectronicsETM coil outputs DQed

To facilitate this investigation, I've DQed the 4 face coil outputs for the two ETMs. EX is currently running with 5 times the series resistance of EY, so it'll be a nice consistency check. Compilation, installation etc went smooth. But when restarting the c1scx model, there was a weird issue - the foton file, C1SCX.txt, got completely wiped (all filter coefficients were empty, even though the filter module names themselves existed). I just copied the chiara backup version, restarted the model, and all was well again.

This corresponds to 8 additional channels, recorded at 16k as float 32 numbers, so in the worst case (neglecting any clever compression algorithms), we are using disk space at a rate of ~4 MB/s more. Seems okay, but anyway, I will remove these DQ channels in a few days, once we're happy we have enough info to inform the coil driver design.

spoke too soon - there was an RFM error for the TRX channel, and restarting that model on c1sus took down all the vertex FEs. Anyways, now, things are back to normal I think. The remaining red light in c1lsc is from the DNN model not running - I forgot to remove those channels, this would've been a good chance! Anyways, given that there is an MLTI in construction, I'm removing these channels from the c1lsc model, so the next time we restart, the changes will be propagated.

For whatever reason, my usual locking scripts aren't able to get me to the PRFPMI locked state - some EPICS channel value must not have been set correctly after the model reboot 😞. I'll debug in the coming days.

Fun times lie ahead for getting the new BHD FEs installed I guess 🤡 ....

Quote:
 

Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).

So we may need a version of the fast coil driver that supports a low noise mode (with large series resistance) and a high-range mode (with lower series resistance for lock acquisition).

Attachment 1: CDS.png
CDS.png
Attachment 2: coilOutDQed.png
coilOutDQed.png
  15489   Thu Jul 16 01:12:22 2020 gautamUpdateBHDIn-air BHD - preparing the LO path

Attachment #1 - The 80mW pickoff was getting clipped on a BNC cable, and not making it to the doubling oven. 😢 .

  • Since the PSL doubled beam isn't used for locking these days, I just didn't notice.
  • I blame the ringdown team, this crazy tee arrangement wasn't the case before.
  • I fixed the situation by changing the cabling such that the beam clears the cables comfortably.

Attachment #2 - PSL green shutter removed. Alignment into the doubling oven is extremely tedious, and so I opted to preserve the capability of recovering the green beam by simply removing a single mirror.

Attachment #3 - The beam path for coupling the LO beam into a fiber.

  • Primary goal was to have easy access to some steering mirrors so that I can optimize alignment into the fiber collimator.
  • I opted to use the NW corner of the PSL table - that's where most of our existing fiber hardware is anyways, and there was sufficient space and easy access over there.
  • 3 Y1 mirrors were installed, using the preferred Polaris mounts and 3/4" post + baseplate hardware. They were labelled Y1-1037-45P so that future workers need not be un-necessarily tortured. The third mirror is not visible in this photograph.
  • Once the collimator arrives, I will mode match this beam into the fiber. Plan is to use the fiber originally used for the mode spectroscopy project. It needs to be moved to the NW corner of the PSL table, and the other end needs to be routed to the AP table (it was brought back to the PSL table to facilitate Anjali's fiber MZ experiment). 
  • There is plenty of space in the beam path for mode-matching lens(es) and polarization control optics.

Attachment #4 shows the BHD photodiodes taken from QIL. 

  • Unfortunately, we could not find the readout electronics. 
  • In the worst case, we can just interface these PDs with the existing Satellite box (associated with the copper OMC).
  • It might be that the OMC cavity can simply be placed on this breadboard, making the whole setup nice and portable.
  • We may want to consider having an OFI between the OMC and the IFO AS beam at some point...
Attachment 1: IMG_8626.JPG
IMG_8626.JPG
Attachment 2: IMG_8627.JPG
IMG_8627.JPG
Attachment 3: IMG_8628.JPG
IMG_8628.JPG
Attachment 4: IMG_8629.JPG
IMG_8629.JPG
  15490   Thu Jul 16 14:41:22 2020 gautamUpdateGeneralFire extinguisher inspection

The (masked) tech accessed all areas in the lab (office area, control room, VEA) between ~230pm-3pm. The laser safety goggles he used have been kept aside for appropriate sanitaiton.

  15491   Fri Jul 17 00:18:13 2020 gautamUpdateGeneralLocking updat
  1. I found that an EPICS channel wasn't reset to the correct value by burtrestore after the FE bootfest yesterday.
    • This cost me the whole of last night, found it finally tonight. 
    • I'll try and modify the locking scripts to better capture such errors, but ideally, we should just use Guardian or something since it's made for this purpose already.
    • Anyways, tonight I was able to re-acquire the PRFPMI lock in a completely scripted way.
  2. Locking CARM on POX remains out of reach.
    • I think this has to do with the fact that the zero-crossing of the CARM and REFL error signals are dependent on the 3f PRCL/MICH error point offsets.
    • So even if the DC gain is right, the fact that we use POX for the digital AO path and REFL for the analog AO path is leading to some conflict I think.
    • Ran out of energy tonight, I'll try again tomorrow.

The DQ channels of the ETM coils were active tonight, so I'll make the coil driver actuation budget over the next couple of days.

  15492   Fri Jul 17 09:03:58 2020 JordanUpdateGeneralPresence at 40m

I will be in the Clean and Bake lab today from 9am to 4pm.

  15493   Sun Jul 19 15:40:15 2020 gautamUpdateBHDIn-air BHD - CDS and wiring summary

Attachment #1 shows the proposed wiring and CDS topology for the in air BHD setup. The PDF document has hyperlinks you can follow to the DCC entries. Main points:

  1. I think we should run the realtime model on c1lsc. This will negate the need for any IPC between c1ioo and c1lsc machines.
  2. I think we have most of the electronics we need already, though I am still in the process of testing the various boards, especially the HV ones.
  3. We may choose to use the switchable whitening feature for the M2 ISS board
    • This would require some BIO channels
    • There are plenty spare in c1lsc, so it's not going to be a show stopper
    • This is why I've not explicitly included a whitening board for now...
  4. The main job seems to be to make a whole bunch of custom cables. For the most part, I think we have the long (~20m) long D9 cables, so I propose just snipping off the connector at one end, and soldering on the appropriate connectors to the correct conductors.
  5. For the homodyne phase control - the proposal is to use a PI PZT with 3 piezoelectric elements. We would drive the 3 elements with the same voltage, by shorting the conductors together (at least that's how I understood Koji's comment), so we'd only need a single DAC channel for this purpose.
    • Need to confirm that the parallel PZT capacitances (each element is ~300 nF so 3 in parallel would be ~900 nF) still allows sufficient actuation bandwidth.
    • If the relative actuation strength of the 3 elements needs to be individually tuned, we may have to use three DAC channels. The D980323 board will allow the driving of 3 independent channels. I have one of these boards in hand, but need to check if it works, and also implement the changes outlined here.
  6. The alignment control has not yet been accounted for
    • We could consider using the in-vacuum PZTs, these were verified to be working ~2018.
    • If we use only 1 steering PZT mirror, we have sufficient free DAC channels available in c1lsc. But if we need both (to avoid clipping for example), then we need more DAC channels - we can either free up one DAFI channel, or install a DAC in the c1lsc expansion chassis
  7. We may want to expand to have a second OMC at some point. In which case we'd need, at the very least
    • 1 more DAC card
    • A HV driver for the second OMC length (could use the Trek driver if we use D980323 for the homodyne phase control).

Please comment if I've overlooked something.

Attachment 1: wiringDiagram.pdf
wiringDiagram.pdf
  15494   Mon Jul 20 17:23:46 2020 gautamUpdateElectronicsCoil drivers for the test masses

Summary:

Looking at the signals to the test mass coils, it seems borderline to me that we will be able to acquire lock and run in a low noise configuration with the same series resistor in the coil driver circuit. The way I see it, options are:

  1. Use a moderately high series resistance (e.g. 5 kohms) for the time being, and go ahead with the HAM-A coil driver.
    • This will mean a current noise of ~3pA/rtHz, which translates to ~3e-18 m/rtHz @ 100 Hz in DARM displacement noise (assuming the ITMs have much higher series resistance than the ETMs).
    • If the lock acquisiton looks smooth, double the resistance to 10 kohms.
    • With 5 kohm series resistance, there is negligible possibility of measuring ponderomotive squeezing for any of the input powers we consider feasible, but this is under the assumption that we will expose coil driver noise, which is very optimistic imho.
  2. Re-design a new coil driver that allows switchable impedance, so we can have a higher noise acquisition mode for acquiring and holding the ALS lock, then transition to a lower noise, lower range config once the RF / BHD lock has been acquired.
    • On paper, this solves all the problems, but the design of such a circuit is probably pretty non-trivial and time consuming.

Details:

I only looked at the ETMs for this study. The assumption is that we will have no length actuation on the ITMs, only local damping and Oplev loops (and maybe some ASC actuation?), which can be sufficiently low-pass filtered such that even with coil de-whitening, we won't have any range issues.

Attachment #1 shows the time-domain traces of the coil driver signals as we transition from POX/POY lock to the ALS lock. There are some transients, but I think we will be able to hold the lock even with a 5 kohm resistor (~twice what is on ETMX right now). From just these numbers, it would seem we can even go up to 10 kohms right away and still be able to acquire lock, especially if we re-design the digital feedback loop to have better low-pass filtering of the high-frequency ALS noise, see the next attachment.

Attachment #2 shows the f-domain picture, once the arm lengths are fully under ALS control (~25 seconds onwards in Attachment #1). The RMS is dominated by high frequency ALS length loop noise, which we can possibly improve with better design of the digital control loop.

Finally, Attachment #3 shows the situation once DARM control has been transitioned over to AS55_Q. Note that the vertex DoFs are still under 3f control, so there is the possibility that we can make this even lower noise. However, one thing that is not factored in here is that we will have to de-whiten these signals to low-pass filter the DAC noise (unless there is some demonstrated clever technique with noise-mons or something to subtract the DAC noise digitally). Nevertheless, it seems like we can run safely with 5 kohms on each ETM coil and still only use ~2000 cts RMS, which is ~1/10th the DAC range (to allow for dealing with spurious transients etc). 

Quote:

Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).

Attachment 1: ALSlock_timeDomain.pdf
ALSlock_timeDomain.pdf
Attachment 2: ALSlock.pdf
ALSlock.pdf
Attachment 3: RFlock.pdf
RFlock.pdf
  15495   Mon Jul 20 17:55:15 2020 gautamUpdateBHDIn-air BHD - preparing the LO path

The LO pickoff has been coupled into a fiber with ~90% MM (8 mW / 9 mW input). While I wait for the DCPD electronics to be found in the Cryo lab, I want to monitor the stability of the pointing, polarization etc, so I'd like to clear some space on the AP table that was occupied for the mode spectroscopy project. If there are no objections before 2pm tomorrow July 21 2020, I will commence this work.

  15497   Tue Jul 21 00:30:24 2020 gautamUpdateBHDIn-air BHD - LO RIN

Attachment #1 shows the RIN of the local oscillator beam delivered to the AP table via fiber. I used a PDA520 to make this measurement, while the electronics for the DCPDs are pending. I don't really have an explanation for the difference between the locked IFO trace vs the not locked trace - we don't have an ISS running (but this first test suggests we should) and the beam is picked off before any cavities etc, so this is a reflection of the state of the FSS servo at the times of measurement?


Tried locking CARM using the hybrid REFL (for AO path) and POX 11 (for MCL path) scheme a bunch of times today, but I had no luck. When the CARM offset is zeroed, the PRMI lock is lost almost immediately. Maybe this is indicative of some excess noise in the POX data stream relative to the REFL signal? The one thing I haven't tried is to take the IFO all the way to the locked state, and then transition the MCL actuation from CM_SLOW to POX11_I.


An SR785 is sitting on the North side of the AP table in the walkway - I will clear it tomorrow.

Attachment 1: LO_RIN.pdf
LO_RIN.pdf
  15498   Tue Jul 21 16:41:46 2020 gautamUpdateBHDPMC assembly space

I decided to use the old EY auxiliary optics table, which is now stored along the east arm about 10 m from the end, as a workspace for assembling the little PMCs. I wiped everything down with isopropanol for general cleanliness, removed the metal plate on the south edge of the table enclosure to allow access, covered the table with some clean Aluminium foil, and then moved the plastic box with PMC parts to the table - see Attachment #1. I haven't actually done any assembly just yet, waiting for more info (if available) on the procedure and implements available...

Attachment 1: IMG_8635.JPG
IMG_8635.JPG
  15500   Fri Jul 24 15:40:59 2020 JordanUpdateVACInstallation of two new UPS units

I installed the Tripp Lite SMX1000RT2U and Tripp Lite Smart1000LCD at the bottom of the 1x8 electronics rack. These are plugged in to power, and are ready for testing. All other cables (serial, usb, etc.) have been left on the table next to the 1x8 rack.

Attachment 1: UPS.jpg
UPS.jpg
  15502   Tue Jul 28 12:22:40 2020 JonUpdateVACVac interlock test today 1:30 pm

This afternoon Jordan is going to carry out a test of the V4 and V5 hardware interlocks. To inform the interlock improvement plan [15499], we need to characterize exactly how these work (they pre-date the 2018 upgrade). I have provided him a sequence of steps for each test and will also be backing him up on Zoom.

We will close V1 as a precaution but there should be no other impact to the IFO. The tests are expected to take <1 hour. We will advise when they are completed.

  15503   Tue Jul 28 13:55:11 2020 HangUpdateBHDExploring bilinear SRCL->DARM coupling

We explore bilinear SRCL to DARM noise coupling mechanisms, and show two cases that by doing BHD readout the noise performance can be improved. In the first case, the bilinear piece is due to residual DHARD motion (see also LHO:45823), and it matters mostly for the low-frequency (<100 Hz) part, and in the second piece the bilinear piece is due to residual SRCL fluctuation and it matters mostly for the a few x 100 Hz part. Details are below:

=================================================

General Model:

We can write the SRCL to DARM transfer function as (Evan Hall's thesis, eq. 2.29)

Z_s2d(f) = C_lf(f) * F^2 * x_D + C_hf(f) * F * dphi_S * x_D    ---- (1)

where

C_lf ~ 1/f^2 and C_hf ~ f are constants at each frequency unless there are major upgrades to the IFO,

F is the finesse of the arm cavity which depends on the alignment, spot position on the TMs, etc., 

dphi_S is the SRCL detuning (wrt the nominal 90 deg value), 

x_D is the DC DARM offset. 

The linear part of this can be removed with feedforward subtractions and it is the bilinear piece that matters, which reads

dZ_s2d = C_lf * <F>^2 * dx_D + C_hf * <F> * <dphi_S> * dx_D

             + 2C_lf * <F> * <x_D>  * dF + C_hf * <dphi_S> * <x_D> * dF

             + C_hf  * <F> * <x_D> * d(dphi_S).     ---- (2)

The first term in (2) is due to residual DARM motion dx_D. This term does not depends on the DC value of DARM offset <x_D> and thus does not depend on doing BHD or DC readout. On the other hand, the typical residual DARM motion is 1 fm << 1 pm of DARM offset. Since the current feedforward reduction factor is about 10 (see both Den Martynov's thesis and Evan Hall's thesis), clearly we are not limited by the residual DARM motion. 

The second term is due to the change in the arm finesse, which can be affected by, e.g., the alignment fluctuation (both increasing the loss due to scattering into 01/10 modes and affecting the spot positon and hence changing the losses), and is likely to be the reason why we see the effect being modulated by DHARD. 

The last term in (2) is due to the residual SRCL fluctuation and is important for the ~ a few x 100 Hz band.

=================================================

DHARD effects. 

As argued above, the DHARD affects the SRCL -> DARM coupling as it changes the finesse in the arm cavity (through scattering into 01/10 modes; in finesse we cannot directly simulate the effects due to spot hitting a rougher location). 

Since in the second term of eq. (2) the LF part depends on the DARM DC offset <x_D>, this effect can be improved by going from DC readout to BHD. 

To simulate it in finesse, at a fixed DARM DC offset, we compute the SRCL->DARM transfer functions at different DHARD offsets, and then numerically compute the derivative \partial Z_s2d / \partial \theta_{DH}. Then multiplying this derivative with the rms value of DHARD fluctuation \theta_{DH} we then know the expected bilinear coupling piece. 

The result is shown in the first attached plot. Here we have assumed a flat SRCL noise of 5e-16 m/rtHz for simplicity (see PRD 93, 112004, 2016). We do not account for the loop effects which further reduces the high frequency components for now. The residual DHARD RMS is assumed to be 1 nrad. 

In the first plot, from top to bottom we show the SRCL noise projection at different DARM DC offsets of (0.1, 1, 10) pm. Since the DHARD alignment only affects the arm finesse starting at quadratic order, it thus matters what DC offset in DHARD we assume. In each pannel, the blue trace is for no DC offset in DHARD and the orange one for a 5 nrad DC offset. As a reference, the A+ sensitivity is shown in grey trace in each plot as a reference. 

We can see if there is a large DC offset in DHARD (a few nrad) and we still do DC readout with a few pm of DARM offset, then the bilinear piece of SRCL can still contaminate the sensitivity in the 10-100 Hz band (bottom panel; orange trace). On the other hand, if we do BHD, then the SRCL noise should be down by ~ x100  even compared to with the top panel. 

(A 5 nrad of DC offset in DHARD coupled with 1 nrad RMS would cause about 0.5% RIN in the arms. This is somewhat greater than the typically measured RIN which is more like <~ 0.2%. See the second plot). 

=================================================

SRCL effect. 

Similarly we can consider the SRCL->DARM coupling due to residual SRCL rms. The approach is very similar to what we did above for DHARD. I.e., we compute Z_s2d at fixed DARM offset and for different SRCL offsets, then we numerically evaluate \partial Z_s2d / \partial dphi_S. A residual SRCL rms of 0.1 nm is then used to generate the projection shown in the third figure. 

Unlike the DHARD effect, the bilinear SRCL piece does not depend on the DC SRCL detuning (for the 50-500 Hz part). It does still depends on the DARM DC offset and therefore could be improved by BHD.

Since we do not include the LP of the SRCL loop in this plot, the HF noise at 1 kHz is artifical as it can be easily filtered out. However, the LP will not be very strong around 100-300 Hz for a SRCL UGF ~ 30 Hz, and thus doing BHD could still have some small improvements for this effect. 

Attachment 1: SRCL_bilin_DHARD.pdf
SRCL_bilin_DHARD.pdf
Attachment 2: ARM_RIN.pdf
ARM_RIN.pdf
Attachment 3: SRCL_bilin_SRCL.pdf
SRCL_bilin_SRCL.pdf
  15504   Tue Jul 28 14:11:14 2020 JonUpdateVACVac interlock test today 1:30 pm

This test has been completed. The IFO configuration has been reverted to nominal.

For future reference: yes, both the V4 and V5 hardware interlocks were found to still be connected and work. A TTL signal from the analog output port of each pump controller (TP2 and TP3) is connected to an auxiliary relay inside the main valve relay box. These serve the purpose of interupting the (Acromag) control signal to the primary V4/5 relay. This interrupt is triggered by each pump's R1 setpoint signal, which is programmed to go low when the rotation speed falls below 80% of the low-speed setting.

Quote:

This afternoon Jordan is going to carry out a test of the V4 and V5 hardware interlocks. To inform the interlock improvement plan [15499], we need to characterize exactly how these work (they pre-date the 2018 upgrade). I have provided him a sequence of steps for each test and will also be backing him up on Zoom.

We will close V1 as a precaution but there should be no other impact to the IFO. The tests are expected to take <1 hour. We will advise when they are completed.

  15505   Wed Jul 29 11:57:59 2020 ranaUpdateBHDIn-air BHD - CDS and wiring summary

3. I agree - this whitening will be handy to have for diagnostics.

4. I think in principle, we can ask a company to make the custom cables for us to save us some hand labor. Rich/Chub probably know the right companies to do small numbers of dirty cables.

5. Can't we just a single Noliac PZT in the same way that the OMC does? Or is the lead time too long?

6. Do we need active steering for this in-air test? I'm not even sure how we would get the alignment signal, so maybe that's a good reason to figure this out.

  15506   Thu Jul 30 16:16:43 2020 gautamUpdateSUSSuspension recovery

This earthquake and friends had tripped all watchdogs. I used the scripted watchdog re-enabler, and released the stuck ITMX (this operation is still requires a human and hasn't been scripted yet). IMC is locked again and all Oplevs report healthy optic alignment.

  15507   Thu Aug 6 00:34:38 2020 YehonathanUpdateBHDMonte Carlo Simulations

I've pushed an MCMC simulation to the A+ BHD repo (filename MCMC_TFs.ipynb). The idea is to show how random offsets around ideal IFO change the noise couplings of different DOFs to readout.

At each step of the simulation:

1. Random offsets for the different DOFs are generated from a normal distribution. The RMSs are taken from experimental data and some guesses and can be changed later. The laser frequency is tuned to match the CARM offset.

These are the current RMS detunings I use:

DOF RMS Taken from
DARM 10fm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
CARM 1fm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
MICH 3pm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
PRCL 1pm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
SRCL 10pm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
OMCL 0.1pm Guess
OMC Breadboard angle 1\mu rad Guess
Differential arm loss 15ppm Guess
BHD BS imbalance 10% Guess
OMC finesse imbalance 5ppm Guess

2. A transfer function is computed for the noisy DOFs.

3. Projected noise is calculated.

These are the noise level for the DOFs:

DOF Noise Taken from
MICH 2e-16 m PHYSICAL REVIEW D 93, 112004 (2016), Fig 9
PRCL 0.5e-17 m PHYSICAL REVIEW D 93, 112004 (2016), Fig 9
SRCL 5e-16 PHYSICAL REVIEW D 93, 112004 (2016), Fig 9
OMCL 2.5e-17*(100/f)^(1/2) LIGO-G1800149
OMC Breadboard angle 1nrad Guess
RIN 2e-9 Optics Letters Vol. 34, Issue 19, pp. 2912-2914 (2009)

 

The attachments show the projected noise levels for the noisy DOFs. Each curve is a different instance of random offsets. The ideal case - "zero offsets" is also shown.

OMC Comm and OMC diff refer to the common and differential length change of the OMCs.

Attachment 1: MICH_Aplus_MCMC.pdf
MICH_Aplus_MCMC.pdf
Attachment 2: PRCL_Aplus_MCMC.pdf
PRCL_Aplus_MCMC.pdf
Attachment 3: SRCL_Aplus_MCMC.pdf
SRCL_Aplus_MCMC.pdf
Attachment 4: OMC_Comm_Aplus_MCMC.pdf
OMC_Comm_Aplus_MCMC.pdf
Attachment 5: OMC_Diff_Aplus_MCMC.pdf
OMC_Diff_Aplus_MCMC.pdf
Attachment 6: OMC_Angle_Yaw_Aplus_MCMC.pdf
OMC_Angle_Yaw_Aplus_MCMC.pdf
Attachment 7: OMC_Angle_Pitch_Aplus_MCMC.pdf
OMC_Angle_Pitch_Aplus_MCMC.pdf
Attachment 8: L0_RIN_Aplus_MCMC.pdf
L0_RIN_Aplus_MCMC.pdf
  15508   Thu Aug 6 22:57:20 2020 gautamUpdatesafetyNew live HV Supplies

Be aware that there is now a KEPCO HV supply that is energized, sitting on the floor immediately adjacent to the OMC rack, east of the AP table. It is currently set to 100 V DC, and a PI PZT installed on the AP table has its 3 PZTs energized by said supply (via an OMC piezo driver). I will post pictures etc of the work from the last 10 days over the weekend.

  15509   Fri Aug 7 11:23:47 2020 ranaUpdateBHDMonte Carlo Simulations

that's great. I think we would like to figure out how to present this so that its clear what the distribution of TFs is. Maybe we can plot the most likely curve as well as a shaded region indicating the 5% and 95% values?

Quote:

I've pushed an MCMC simulation to the A+ BHD repo (filename MCMC_TFs.ipynb). The idea is to show how random offsets around ideal IFO change the noise couplings of different DOFs to readout.

and then we add the loops

  15512   Mon Aug 10 07:13:00 2020 YehonathanUpdateBHDMonte Carlo Simulations

I fixed some stuff in the MCMC simulation:

1. Results are now plotted as shades from minimum to maximum. I tried making the shade the STD around a mean but it doesn't look good on a log scale when the STD is bigger than the mean.

2. Added comparison with aLigo. The OMCL diff and comm motions in A+ are both compared to the single OMCL DOF of aLigo.

3. I fixed a serious error in the code that produced incorrect results.

4. Imbalances in the IFO such as differential arm loss are generated randomly at the beginning and stay fixed for the rest of the simulation instead of being treated as an offset.

5. The simulation now runs with maxtem=2. That is, TEM modes up to 2nd order are considered.

The results are attached.

 

Attachment 1: MICH_AplusMCMC.pdf
MICH_AplusMCMC.pdf
Attachment 2: PRCL_AplusMCMC.pdf
PRCL_AplusMCMC.pdf
Attachment 3: SRCL_AplusMCMC.pdf
SRCL_AplusMCMC.pdf
Attachment 4: OMC_Comm_AplusMCMC.pdf
OMC_Comm_AplusMCMC.pdf
Attachment 5: OMC_Diff_AplusMCMC.pdf
OMC_Diff_AplusMCMC.pdf
Attachment 6: OMC_Angle_Yaw_AplusMCMC.pdf
OMC_Angle_Yaw_AplusMCMC.pdf
Attachment 7: OMC_Angle_Pitch_AplusMCMC.pdf
OMC_Angle_Pitch_AplusMCMC.pdf
Attachment 8: L0_RIN_AplusMCMC.pdf
L0_RIN_AplusMCMC.pdf
  15513   Mon Aug 10 16:52:04 2020 gautamUpdateBHDWorkable setup prepared

All the details are in E2000436, and documents linked from there, I think an elog would be much too verbose. In summary, a workable setup consisting of

  • 2 DCPDs interfaced with the realtime CDS system. Note that because this circuit is single-ended, while the AA and ADC are differential receiving, there is an overall gain of 0.5. Explicitly, for the 300 ohm DC transimpedance, the conversion is ~350 cts/mW.
  • A local oscillator beam delivered via fiber that is mode-matched (roughly) with the IFO AS beam.
  • A PZT mounted mirror to control the homodyne phase. The PZT (S320) is an obsolete part and it's hard to find a datasheet for it, but if its specs are comparable to the more modern S330, the full stroke is 10 um, for a max applied voltage of 100 V DC, so 100nm/V. c.f. 200V for 3um full stroke of the Noliac.

was prepared.

Last night, I locked the PRMI with the carrier resonant, and convinced myself that the DCPD null stream was sensing the MICH degree of freedom (while it was locked on AS55_Q) with good SNR below ~60 Hz. Above ~60 Hz, in this configuration, the ADC noise was dominating, but by next week, I'll have a whitening board installed that will solve this particular issue. With the optical gain of MICH in this configuration, the ADC noise level was equivalent to ~500 nrad/rtHz of phase noise above ~60 Hz (plots later).

Now, I can think about how to commission this setup interferometrically.

  15514   Tue Aug 11 23:20:29 2020 gautamUpdateBHDSome first tests with air BHD setup

Some tests done today:

All of these tests were done with the PRMI locked with carrier resonant in the recycling cavity (i.e. sidebands rejected to REFL port). I then actuated the BS length DOF with a sine wave at 311.1 Hz, 40 cts amplitude (corresponding to ~8 pm of peak-to-peak displacement).

  1. Attempt to balance the DCPDs
    • I tried to tune the digital gains of the two DCPDs so as to minimize the appearance of this line in the SUM channel
    • but no matter how I tuned the gains, I couldn't make the line in the SUM channel disappear entirely - in fact, the best I could do was to make the line height in SUM and NULL channels (yes I recognize the poor channel name choice, I'll change "NULL" to "DIFF" at the next model recompile) the same. See Attachment #1.
    • The lobes around the main peak are indicative of some scattering?
    • Attachment #2 shows a wider frequency range. The homodyne phase isn't controlled, so the "NULL" channel is not necessarily measuring the correct quadrature to be sensing MICH motion.
    • I think I can back out something about the contrast defect from this fact, but I need to go back to some modeling.
  2. A simple test of the homodyne phase actuator
    • I wanted to check that this PI S320 piezo actually allows me to actuate the optical path length of the local oscillator.
    • I'm using the OMC HV driver to drive said PZT - so there are two DAC channels available, one to dither the optic and one to apply a control signal. I think mainly this is to avoid using up DAC range for the dither signal, the overall dynamic range is still limited by the HV supply.
    • I can't find the maximum voltage that can be applied on the datasheet - so conservatively, I limited the HV output to saturate at 100 V DC, as this is the maximum for the S330 piezos used for green steering, for which there is a manual.
    • The S320 manual does say the full stroke of each PZT element is 10 um - so the actuation coefficient is ~100 nm/V. I then drove this actuator with a sine wave of 500 cts amplitude, at 314.1 Hz (corresponding to 15 nm of motion). With only the LO beam incident on the PDs, I saw no signal in either DCPD - as expected, so this was good.
    • Then, with the PRMI locked, I repeated the test. If there is no DC light field (as expected for the PRMI in this configuration), I wouldn't expect this drive signal to show up in the DCPDs. But in fact, I do. Again, this supports the presence of some (for now unquantified) contrast defect.

While it would seem from these graphs that the RIN of the LO beam at these frequencies is rather high, it is because of the ADC noise. More whitening (to be installed in the coming days) will allow us to get a better estimate, should be ~1e-6 I think.

I was just playing today, still need to setup some more screens, DTT templates etc to do more tests in a convenient way.

Now, I can think about how to commission this setup interferometrically.

Attachment 1: PRMI_RFlock.pdf
PRMI_RFlock.pdf
Attachment 2: PRMI_RFlock_fullscale.pdf
PRMI_RFlock_fullscale.pdf
  15515   Wed Aug 12 17:36:42 2020 gautamUpdateCDSTiming distribution slot availability

See Attachment #1. J8 was connected to a "LASTI timing slave" sitting in the rack that Chiara lives in - we don't use this for anything and I confirmed that there was no effect on the RTCDS when I pulled that fiber out. The LASTI timing slave also had a blinky that was blinking when the fiber was plugged in - which I take to believe that the slot works. 

Can we get away with just using these two available slots, J8 and J13? Do we really need three new expansion chassis?

Attachment 1: IMG_8706.JPG
IMG_8706.JPG
  15516   Wed Aug 12 17:42:58 2020 gautamUpdateElectronicsPhotodiode inventory

See Attachments #1 and #2. We don't have any Q3000 QPDs in hand, at least not in the photodiode box stored in the clean optics cabinet at the south end. I also checked a cabinet along the east arm where we store some photodiodes - but didn't find any there either. The only QPDs we have in hand are the YAG-444-4AH, which I believe is what is used in the iLIGO WFS heads.

So how many do we want to get?

Attachment 1: IMG_8709.JPG
IMG_8709.JPG
Attachment 2: IMG_8708.JPG
IMG_8708.JPG
  15517   Wed Aug 12 18:08:54 2020 gautamUpdateElectronicsNumber of the beast

The "source" output of the SR785 has a DC offset of -6.66 V. I couldn't make this up.

Upshot is, this SR785 is basically not usable for TF measurements. I was using the unit to characterize the newly stuffed ISC whitening board. The initial set of measurements were sensible, and at some point, I started getting garbage data. Unclear what the cause of this is. AFAIK, we don't have any knob to tune the offset - adjusting the "offset" in the source menu, I can change the level of the offset, but only by ~1 V even if I apply an offset of 10 V. I also tried connecting the ground connection on the rear of the SR785 to the bench power supply ground, no change.

Do we have to send this in for repair?

Attachment 1: IMG_8710.JPG
IMG_8710.JPG
  15518   Wed Aug 12 20:14:06 2020 KojiUpdateCDSTiming distribution slot availability

I believe we will use two new chassis at most. We'll replace c1ioo from Sun to Supermicro, but we recycle the existing timing system.

  15519   Wed Aug 12 20:15:42 2020 KojiUpdateElectronicsNumber of the beast

Grrr. Let's repair the unit. Let's get a help from Chub & Jordan.

Do you have a second unit in the lab to survive for a while?

  15520   Wed Aug 12 20:16:52 2020 KojiUpdateElectronicsPhotodiode inventory

When I tested Q3000 for aLIGO, the failure rate was pretty high. Let's get 10pcs.

ELOG V3.1.3-