40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 32 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  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.

  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.

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

  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?

  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.

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

You can activate all 3axis

 

  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.

  15482   Wed Jul 15 17:46:05 2020 anchalSummaryALSNoise budget for ALS

I started my attempt on noise budgeting of ALS by going back to how Kiwamu did it and adding as many sources as I could find up till now. This calculation is present in ALS_Noise_Budget notebook. I intend to collect data for noise sources and all future work on ALS in the ALS repo.

The noise budget runs simulink through matlab.engine inside python and remaining calculations including the pygwinc ones are done in python. Please point out any errors that I might have done here. I still need to add noise due to DFD and the ADC after it. For the residual frequency noise of AUX laser, I have currently used an upper limit of 1kHz/rt Hz at 10 Hz free-running frequency noise of an NPRO laser.

Attachment 1: ALS_nb.pdf
ALS_nb.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
  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
  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
  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.

  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.

  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.

  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?

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

  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.

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

  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.

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

  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. 
  15465   Thu Jul 9 18:00:35 2020 JonConfigurationVACUPS replacements

Chub has placed the order for two new UPS units (115V for TP2/3 and a 220V version for TP1).

They will arrive within the next two weeks.

Quote:

​I looked into how the new UPS devices suggested by Chub would communicate with the vac interlocks. There are several possible ways, listed in order of preference:

  • Python interlock service directly queries the UPS via a USB link using the (unofficial) tripplite package. Direct communication would be ideal because it avoids introducing a dependency on third-party software outside the monitoring/control capability of the interlock manager. However the documentation warns this package does not work for all models...
  • Configure Tripp Lite's proprietary software (PowerAlert Local) to send SYSLOG event messages (UDP packets) to a socket monitored by the Python interlock manager.
  • Configure the proprietary software to execute a custom script upon an event occurring. The script would, e.g., set an EPICS flag channel which the interlock manager is continually monitoring.

I recommend we proceed with ordering the Tripp Lite 36HW20 for TP1 and Tripp Lite 1AYA6 for TP2 and TP3 (and other 120V electronics). As far as I can tell, the only difference between the two 120V options is that the 6FXN4 model is TAA-compliant.

  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
  15463   Thu Jul 9 16:16:20 2020 gautamUpdateComputersrossa: graphics driver issues?

I noticed these streaky lines again today (but they were not a problem last night). It is annoying if we have to reboot this machine all the time. I wonder if this has something to do with missing drivers. When I ran sudo apt update && sudo apt upgrade, I got several lines like (this isn't the whole stack trace)

W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/ucode_unload.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/ucode_load.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/unload_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/bl.bin for module nouveau

Is this indicative of the graphics drivers being installed incorrectly? I am hesitant to mess with this because I think in the past, it was always trying to update some graphics driver that crashed the whole machine into some weird state where we have to wipe the drive and do a fresh re-install of the OS.

Should we just follow these instructions? The graphics card is apparently Quadro P400, which is one of the supported ones according to the list of supported devices.

Or just swap donatella and rossa monitors and defer the problem for later?

Quote:

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

  15462   Thu Jul 9 16:02:33 2020 JonHowToCDSProcedure for setting up BHD front-ends

Here is the procedure for setting up the three new BHD front-ends (c1bhd, c1sus2, c1ioo - replacement). This plan is based on technical advice from Rolf Bork and Keith Thorne.

The overall topology for each machine is shown here. As all our existing front-ends use (obsolete) Dolphin PCIe Gen1 cards for IPC, we have elected to re-use Dolphin Gen1 cards removed from the sites. Different PCIe generations of Dolphin cards cannot be mixed, so the only alternative would be to upgrade every 40m machine. However the drivers for these Gen1 Dolphin cards were last updated in 2016. Consequently, they do not support the latest Linux kernel (4.x) which forces us to install a near-obsolete OS for compatibility (Debian 8).

Hardware

Software

  • OS: Debian 8.11 (Linux kernel 3.16)
  • IPC card driver: Dolphin DX 4.4.5 [works only with Linux kernel 2.6 to 3.x]
  • I/O card driver: None required, per the manual

Install Procedure

  1. Follow Keith Thorne's procedure for setting up Debian 8 front-ends
  2. Apply the real-time kernel patches developed for Debian 9, but modified for kernel 3.16 [these are UNTESTED against Debian 8; Keith thinks they may work, but they weren't discovered until after the Debian 9 upgrade]
  3. Install the PCIe expansion cards and Dolphin DX driver (driver installation procedure)
  15461   Thu Jul 9 09:22:44 2020 JordanUpdateGeneralPresence at 40m

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

  15460   Wed Jul 8 22:50:33 2020 gautamUpdateComputersrossa: more symlinks

I wanted to try using rossa as my locking workstation today. However, a few problems became quickly evident. Basically, any of our scripts that rely on the cdsutils package (there are MANY) will not work on rossa, because of some library error. This machine is running Debian 10, while the cdsutils package is being loaded from a pre-compiled install on the shared drive, so perhaps this isn't surprising?

Digging a little more, I found that actually, a version of cdsutils that actually works with python3 is actually shipped with the standard cds-workstation meta-package. This is great news, and we should try and use this where possible I guess. Deferring further debugging for daytime work.

Anyway, I added a symlink: sudo ln -s /usr/lib/x86_64-linux-gnu/libncurses.so.6 /usr/lib/x86_64-linux-gnu/libncurses.so.5, and installed wmctrl using sudo apt install wmctrl

  15459   Wed Jul 8 08:51:35 2020 JordanUpdateGeneralPresence at 40m

I will be in the clean and bake lab today from 9am to 3pm.

  15458   Tue Jul 7 14:06:10 2020 gautamUpdateASCSome more thoughts about ASC

Summary:

I want to be able to run the dither alignment servo with the PRFPMI locked - I've been thinking about what the scheme should be, and I list here some questions I had while thinking about this.

Details:

  1. ITM Oplev DC coupling
    • In the current scheme, I DC couple the ITM Oplev servos after the arms have been aligned to maximize POX/POY transmission.
    • However, looking back at data from when the CARM offset is reduced (e.g. Attachment #1), it looks like the ITMs are being torqued quite a bit during this process (ITMX PIT changes by ~20urad, ITMY YAW by ~10urad in this particular lock attempt). 
    • So the spots are not actually being centered on the test-masses? I guess the spot position on ITMX isn't actually controlled because we have only one actuator (BS) for the XARM beam axis. Is it unexpected that ITMY gets torqued so much? 
    • It is unclear what would happen if the ITM Oplev servos are not DC coupled. I wonder if I'd still be able to reach the high circulating powers and then rely solely on the TR QPDs for the arm cavity angular control.
    • Another possibility is to offload the DC part of the control signal to the optic's slow bias voltage slider, and then turn off the DC coupling. After that, the dither alignment can optimize the cavity alignment.
  2. Dither alignment at high circulating power
    • think that the system should work with the same settings as for the POX/POY locking, with the following changes:
      • Scale the overall loop gain by the arm transmission.
      • Change LSC2ASS matrix element from XARM/YARM ---> DARM.
        Does this sound right?
    • In light of the above, I was thinking that we should introduce a gain scaling field in the c1ass RTCDS model (like we have for the LSC power normalization matrix). Is it worth to go through the somewhat invasive process of model recompilation etc?
    • With the PRFPMI locked, I am wondering if I can simultaneously run the dither alignment loops for all the DoFs. Probably not, especially for MICH, since the actuator is the BS, which is also the actuator for the XARM loop?
Attachment 1: ITM_OL_DCcoupling.png
ITM_OL_DCcoupling.png
  15457   Mon Jul 6 17:41:19 2020 gautamUpdateLSCAn LSC puzzler

Last Tuesday evening, while attempting the PRFPMI locking, I noticed a strange feature in the LSC signals, which is shown in Attachment #1 (the PDF exported by dataviewer is 14MB so I upload the jpeg instead). As best as I can tell, the REFL33 and POP22 channels show an abrupt jump in the signal levels, while the other channels do not. POP110 shows a slight jump at around the same time, and the large excursion in AS110_Q actually occurs a few seconds later, and is probably some angular excursion of the PRC/BS. I'm struggling to interpret how this can be explained by some interferometric mechanism, but haven't come up with anything yet. The LO for the 3f error signals is the 2f field, but then why doesn't the POP110 channel show a similar jump if there is some abrupt change in the resonant condition? Is such a change even feasible from a cavity length change point of view? Or did the sideband frequency somehow abruptly jump? But if so, why is the jump much more clearly visible in one sideband than the other?

Does anyone have any ideas as to what could be going on here? This may give some clue as to what's up with the weird sensing matrices, but may also be something boring like broken electronics... 

Attachment 1: LSCsignals.jpg
LSCsignals.jpg
  15456   Mon Jul 6 15:10:40 2020 JonSummaryBHD40m --> A+ BHD design analysis

As suggested last week, Hang and I have reviewed the A+ BHD status (DRD, CDD, and reviewers' comments) and compiled a list of key unanswered questions which could be addressed through Finesse analysis.

In anticipation of others helping with this modeling effort, we've tried to break questions into self-contained projects and estimated their level of difficulty. As you'll see, they range from beginner to Finesse guru.

  15455   Mon Jul 6 12:51:41 2020 gautamUpdateComputersrossa: resolvconf installed

Indeed, this is now fixed by following instructions from here. I rebooted rossa at ~1250 PDT and confirmed that resolv.conf didn't get overwritten. The resolv.conf file also now has the following useful lines at the head:

~>cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
Quote:

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

  15454   Mon Jul 6 12:43:02 2020 ranaUpdateComputersrossa: lib symlink

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

  15453   Mon Jul 6 08:48:15 2020 JordanUpdateGeneralPresence at 40m

I will be in the Clean and Bake lab today from 8:30am to 4pm

  15452   Mon Jul 6 00:37:28 2020 gautamUpdateComputersrossa: lib symlink

This is strange - I was definitely able to launch medm when I was working on this machine remotely on Friday. But now, there does seem to be a problem with this shared library being missing.

First of all, I installed mlocate to find where the shared library files are installed. Then I made the symlink, and now sitemap seems to work again.

Weirdly, my changes to /etc/resolv.conf got overwritten somehow. Was this machine rebooted? Uptime suggests it's only been running for ~6 hours at the time of writing of this elog.

sudo apt install mlocate
sudo updatedb
sudo ln -s /usr/lib/x86_64-linux-gnu/libreadline.so.7 /usr/lib/x86_64-linux-gnu/libreadline.so.6
Quote:

when I try 'sitemap' on rossa I get:

medm: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory

  15451   Sun Jul 5 18:39:57 2020 ranaUpdateComputersrossa: printer

I did

sudo usermod -a -G lpadmin controlscheeky

and then was able to add Grazia to the list of printers for Rossa by following the instructions on the 40m Wiki. yes


I installed color syntax highlighting on Rossa using the internet (https://superuser.com/questions/71588/how-to-syntax-highlight-via-less). Now if you do 'less genius_code.py', it will be highlighting the python syntax.


when I try 'sitemap' on rossa I get:

medm: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
 

  15450   Sun Jul 5 18:25:42 2020 ranaUpdateElectronicsWFS characterization

in the lab, checkin on the WFS

Sun Jul 5 18:25:50 2020

I redid Gautam's measurements to get a baseline before changing the head, and my results are very different: To me it looks like the WFS2 quadrants are all OK.

 

Measurement Details:

  1. The whole AG4395 + breadboard Jenne laser is wheeled over next to the SW side of the AP table.
  2. The output of the 1611 goes into channel R of the 4395
  3. I disconnected all the LEMO cables from the head and then plugged a LEMO-BNC cable into the plugs one at a time. The existing LEMO connectors, which take the signals back to the demode board, were all a little loose, so I adjusted them with some pliers (see video).
  4. The Atten = 0 dB for all AG4395 channels
  5. Source drive = 0 dBm. Checked with a -10 dBm drive that there was no change in the observed TFs, so I guess a 0 dBm drive doesn't make things nonlinear.
  6. When I first turned the setup on, the Yellow 'limit' light was ON on the ILX laser current driver, so maybe the modulation wasn't getting to the laser diode as we wish.
  7. did not change any WFS MEDM settings for these measurements. Not sure if any of those buttons work anyway.

I've left the setup as is in case either me or Gautam want to double check. If we're agreed on this response, I'll remove the notches and disable the RF attenuators.

Sun Jul 5 21:42:45 2020

Attachment 1: WFS_attenOff.pdf
WFS_attenOff.pdf
  15449   Sun Jul 5 16:14:41 2020 ranaUpdateComputersrossa re-re-revival

maybe we should make a "dd" copy of pianosa in case rossa has issues and someone destroys pianosa by accidentally spilling coffee on it.

So, in summary, rossa is now all set up for use during lock acquisition. However, until this machine has undergone a few months of testing, we should freeze the pianosa config and not mess with it.

  15448   Thu Jul 2 16:51:23 2020 JordanUpdateGeneralBathroom Science

As part of an ongoing effort to improve airflow in workspaces/bathrooms on campus, I have installed an air scrubber unit in each of the bathrooms at the 40m lab.

Attachment 1: AirScrubber40m.jpg
AirScrubber40m.jpg
  15447   Wed Jul 1 18:16:09 2020 gautamUpdateComputersrossa re-re-revival

In an effort to make a second usable workstation, I did the following (remotely) on rossa today (not necessarily in this order, I wasn't maintaining a live log so I forgot):

  1. Fixed /etc/resolv.conf, so that the other martian machines can be found.
  2. Copied over .bashrc file, and the appropriate lines from /etc/fstab from pianosa to rossa.
  3. Ran sudo apt install nfs-common. Then ran sudo mount -a to get /cvs/cds mounted.
  4. Made symlinks for /users and /opt/rtcds , and /ligo. All of these are used by various environment-setting scripts and I chose to preserve the structure, though why we need so many symlinks, I don't know...
  5. Set up the shell variable $NDSSERVER using export NDSSERVER=fb:8088. I'm not sure how, but I believe DTT, awggui etc use this on startup to get the channel list (any
  6. Followed instructions from Erik von Reis at LHO to install the cds workstation packages and dependencies. Worked like a charm 🎃
  7. As a test, I plotted the accelerometer spectra in DTT, see Attachment #1. I also launched foton from inside awggui, and confirmed that the sample rate is inherited and I could designate a filter. But I haven't yet run the noise injection to test it, I'll do that the next time I'm in the lab.
  8. Also checked that medm, StripTool and ndscope, and anaconda python all seem to work 👍🏾.

So, in summary, rossa is now all set up for use during lock acquisition. However, until this machine has undergone a few months of testing, we should freeze the pianosa config and not mess with it.

Note that this version of the "crtools" is rather new. Please, use them and if there is an issue, report the errors! I am going to occassionally try lock acquisition using rossa. 

Quote:

wiped and install Debian 10 on rossa today

still to be done: config it as CDS workstation

please don't try to "fix" it in the meantime

Attachment 1: MCacc.pdf
MCacc.pdf
  15446   Wed Jul 1 18:03:04 2020 JonConfigurationVACUPS replacements

​I looked into how the new UPS devices suggested by Chub would communicate with the vac interlocks. There are several possible ways, listed in order of preference:

  • Python interlock service directly queries the UPS via a USB link using the (unofficial) tripplite package. Direct communication would be ideal because it avoids introducing a dependency on third-party software outside the monitoring/control capability of the interlock manager. However the documentation warns this package does not work for all models...
  • Configure Tripp Lite's proprietary software (PowerAlert Local) to send SYSLOG event messages (UDP packets) to a socket monitored by the Python interlock manager.
  • Configure the proprietary software to execute a custom script upon an event occurring. The script would, e.g., set an EPICS flag channel which the interlock manager is continually monitoring.

I recommend we proceed with ordering the Tripp Lite 36HW20 for TP1 and Tripp Lite 1AYA6 for TP2 and TP3 (and other 120V electronics). As far as I can tell, the only difference between the two 120V options is that the 6FXN4 model is TAA-compliant.

  15445   Wed Jul 1 12:50:40 2020 gautamUpdatePEMMC1 accelerometers plugged in

I re-connected the 3 accelerometers located near the MC1/MC3 chamber. It was a bit tedious to get the cabling sorted - I estimate the cable is ~80m long, and the excess length had to be wound around a spool (see Attachment #1), which wasn't really a 1 person job. It's neat-ish for now, but I'm not entirely satisfied. I think we should get shorter cables (~20m), and also mount the pre-amp/power units in a rack instead of leaving it on the floor. The pre-amp settings are x100 for all three channels. The MC2 channels are powered, but are unconnected to the seismometers - it was too tedious to unroll the other spool yesterday. Apart from this, the cable for the "Z" channel had to be re-seated in the strain relief clamp.

I did not enable any of the CDS filters that convert the raw signal into physical units, so for now, these channels are just recording raw counts.

Update 7pm: the spectra in the current config are here - not sure what to make of the MC2_Z channel appearing to show lower noise?

Update July 13 2020 430pm: This afternoon, I hooked up the MC2 accelerometer channels too...

Attachment 1: IMG_8617.JPG
IMG_8617.JPG
Attachment 2: IMG_8616.JPG
IMG_8616.JPG
  15444   Wed Jul 1 08:51:52 2020 JordanUpdateGeneralPresence at 40m

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

  15443   Tue Jun 30 22:00:04 2020 gautamUpdateElectronicsGlitchy POX resurfaces

This problem reared its ugly head again. I am inclined to believe the problem is electronic and not on the light, since the POY channels seem immune to this issue (see Attachment #1). I will investigate in the daytime tomorrow. Note that while the POX photodiode head has ~twice the transimpedance than POY (per measurement), the POY signal gets amplified by a ZHL-500-HLN amplifier before heading to the demod electronics (nominal gain is 19dB = x9). There is also some imbalance in the light level at the photodiodes I guess, because overall, the PDH fringe is ~twice as large for the Y arm as the X arm. Basically, the y-axes of the attached plot cannot be directly compared between POX and POY.

Mostly this is an annoyance - right now, the POX signal is only used for locking and dither aligning the X arm cavity, and so once that is done, the locking can proceed (as long as the other channels, e.g. REFL11, aren't glitching as well...)

Attachment 1: glitchyPOX.jpg
glitchyPOX.jpg
  15442   Tue Jun 30 10:59:16 2020 gautamUpdateLSCThree sensing matrices

Summary:

I injected some sensing lines and measured their responses in the various photodiodes, with the interferometer in a few different configurations. The results are summarized in Attachments #1 - #3. Even with the PRMI (no arm cavities) locked on 1f error signals, the MICH and PRCL signals show up in nearly the same quadrature in the REFL port photodiodes, except REFL165. I am now thinking if the output (actuation) matrix has something to do with this - part of the MICH control signal is fed back to the PRM in order to minimize the appearance of the MICH dither in the PRCL error signal, but maybe this matrix element is somehow horribly mistuned?

Details:

Attachment #1:

  • ETMs were misaligned and the PRMI was locked with the carrier resonant in the cavity (i.e. sidebands reflected).
  • The locking scheme was AS55_Q --> MICH and REFL11_I --> PRCL.

Attachment #2:

  • The PRFPMI was locked. The vertex DoFs were still under control using 3f error signals (REFL165_I for PRCL and REFL165_Q for MICH).
  • Still, the MICH/PRCL degeneracy in all photodiodes except REFL165 persists.

Attachment #3:

  • Nearly identical configuration to Attachment #2.
  • The main difference here is that I applied some offsets to the MICH and PRCL error points.
  • The offsets were chosen so that the appearance of a ~300 Hz dither in the length of MICH/PRCL was nulled in the AS110_Q / POP22_I signals respectively.
  • For the latter, the appearance of this peak in the POP110_I signal was also nulled, as it should be if our macroscopic PRC length is set correctly.
  • The offsets that best nulled the peak were 110 cts for PRCL, 25 cts for MICH. The measured sensing response is 1e12 cts/m for PRCL in REFL165_I and 9.2e11 cts/m for MICH in REFL165_Q. So these offsets, in physical units, are: 110 pm for PRCL and 27 pm for MICH. They seem like reasonable numbers to me - the PRC linewidth is ~7.5 nm, so the detuning without any digital offset applied is only 1.5% of the linewidth.
  • Note that I changed the POP22/POP110 demod phases to maximize the signal in the I quadrature. The final numbers were -124 degrees / -10 degrees respectively.
  • Yet another piece of evidence suggesting these were the correct offsets is that the DC value of POX and POY were zero on average after these offsets were applied.
  • However, the MICH/PRCL responses in the 1f REFL port photodiodes remain nearly degenerate.

Some other mysteries that I will investigate further:

  1. While POP22 indicated stable buildup of 11 MHz power in the PRC, I couldn't make any sense of the AS110 signals at the dark port - there was large variation of the signal content in the two quadratures, so unlike the POP signals, I couldn't find a digital demod phase that consistently had all the signal in one of the two quadratures. This is all due to angular fluctuations?
  2. My ASC simulations suggest that the POP QPD is a poor sensor of PRM motion when the PRFPMI is locked. However, I find that turning on a feedback loop with the POP QPD as a sensor and the PRM as the actuator dramatically reduces the low-frequency fluctuations of the arm cavity carrier buildup. 🤔

I blew the long lock last night because I forgot to not clear the ASS offsets when trying to find the right settings for running the ASS system at high power. Will try again tonight...

Quote:

Lock the PRMI on carrier and measure the sensing matrix, see if the MICH and PRCL signals look sensible in 1f and 3f photodiodes.

Attachment 1: PRMI_1f_20200625sensMat.pdf
PRMI_1f_20200625sensMat.pdf
Attachment 2: PRFPMI_20200629sensMat.pdf
PRFPMI_20200629sensMat.pdf
Attachment 3: PRFPMI_20200629sensMat_wOffset.pdf
PRFPMI_20200629sensMat_wOffset.pdf
ELOG V3.1.3-