40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 121 of 341 Not logged in
ID Date Author Type Category Subject
13898   Wed May 30 16:12:30 2018 Jonathan HanksSummaryCDSLooking at c1oaf issues

When c1oaf starts up there are 446 gain channels that should be set to 0.0 but which end up at 1.0.  An example channel is C1:OAF-ADAPT_CARM_ADPT_ACC1_GAIN.  The safe.snap file states that it should be set to 0.  After model start up it is at 1.0.

We ran some tests, including modifying the safe.snap to make sure it was reading the snap file we were expecting.  For this I set the setpoint to 0.5.  After restart of the model we saw that the setpoint went to 0.5 but the epics value remained at 1.0.  I then set the snap file back to its original setting.  I ran the epics sequencer by hand in a gdb session and verified that the sequencer was setting the field to 0.  I also built a custom sequencer that would catch writes by the sdf system to the channel.  I only saw one write, the initial write that pushed a 0.  I have reverted my changes to the sequencer.

The gain channel can be caput to the correct value and it is not pushed back to 1.0.  So there does not appear to be a process actively pushing the value to 1.0.  On Rolfs sugestion we ran the sequencer w/o the kernel object loaded, and saw the same behavior.

This will take some thought.

5864   Thu Nov 10 16:44:54 2011 MirkoUpdateAdaptive FilteringLooking into MC_F & PSL misalignment

[Den, Mirko]

While doing the things below we accidentally misaligned the PSL laser. Thanks to Suresh and Jenne for realigning!!

There are a lot of strange features in MC_F (see for example http://nodus.ligo.caltech.edu:8080/40m/5738 )
To get some better understanding of the signals in the control loop we looked some more into what happens to the MC feedback signal after it exits the MC servo board (D040180 see DCC).

The MC_F signal is actually the servo signal: http://nodus.ligo.caltech.edu:8080/40m/5695
The Thorlabs temperature controller is actually used in the PZT path!

We measured the LP filter in the PZT path (that is kind of mislabeled as temp.)

5867   Thu Nov 10 22:00:38 2011 MirkoUpdateAdaptive FilteringLooking into MC_F & PSL misalignment

 Quote: [Den, Mirko] While doing the things below we accidentally misaligned the PSL laser. Thanks to Suresh and Jenne for realigning!! There are a lot of strange features in MC_F (see for example http://nodus.ligo.caltech.edu:8080/40m/5738 ) To get some better understanding of the signals in the control loop we looked some more into what happens to the MC feedback signal after it exits the MC servo board (D040180 see DCC). The MC_F signal is actually the servo signal: http://nodus.ligo.caltech.edu:8080/40m/5695 The Thorlabs temperature controller is actually used in the PZT path!  We measured the LP filter in the PZT path (that is kind of mislabeled as temp.)

### We looked into the signal from the MC servo board at different position at the PSL table.

We looked into the FB going into the temp. and PZT parts of the FB.
Temp.:

PZT:

We also looked at the signal in just in front of the FSS box No idea why the elog doesn't preview these pdfs.

Lots of extra noise there. We will check out where that comes from.

15276   Fri Mar 13 20:00:50 2020 JonUpdateComputersLoopback monitoring for slow machines

### Summary

Today I finished implementing loopback monitors of the up/down state of the slow controls machines. They are visible on a new MEDM screen accessible from Sitemap > CDS > Slow Machine Status (pictured in attachment 1). Each monitor is a single EPICS binary channel hosted by the slow machine, which toggles its state at 1 Hz (an alive "blinker"). For each machine, the monitor is defined by a separate database file named c1[machine]_state.db located in the target directory.

This is implemented for all upgraded machines, which includes every slow machine except for c1auxey. This is the next and final one slated for replacement.

### Implementation

The blinkers are currently implemented as soft channels, but I'd like to ultimately convert them to hard channels using two sinking/sourcing BIO units. This will require new wiring inside each Acromag chassis, however. For now, as soft channels, the monitors are sensitive to a failure of the host machine or a failure of the EPICS IOC. As hard channels, they will additionally be sensitive to a failure of the secondary network interface, as has been known to happen.

Each slow machine's IOC had to be restarted this afternoon to pick up the new channels. The IOCs were restarted according to the following procedure.

c1auxex

• Disabled OPLEV servos on ETMX
• Zeroed slow biases
• Disabled watchdog
• Restarted IOC
• Reverted 1-3

​c1vac

• Closed V1, VM1
• Restarted IOC
• Returned valves to original state

c1psl

• Disabled IMC autolocker
• Closed PSL shutter
• Restarted IOC
• Reverted 1-2

c1iscaux

• ​Restarted IOC

c1susaux

• Disabled IMC autolocker
• Closed shutter
• Disabled OPLEV servos on: MC1, MC2, MC3, BS, ITMX, ITMX, PRM, SRM
• Zeroed slow biases
• Disabled watchdogs
• Restarted IOC
• Reverted 1-5

The intial recovery of c1susaux did not succeed. Most visibly, the alignment state of the IFO was not restored. After some debugging, we found that the restart of the modbus service was partially failing at the final burt-restore stage. The latest snapshot file /opt/rtcds/caltech/c1/burt/autoburt/latest/c1susaux.snap was not found. I manually restored a known good snapshot from earlier in the day (15:19) and we were able to relock the IMC and XARM. GV and I were just talking earlier today about eliminating these burt-restores from the systemd files. I think we should.

Attachment 1: Screen_Shot_2020-03-13_at_7.59.55_PM.png
718   Tue Jul 22 22:25:31 2008 ranaUpdateLSCLooptickle for existing 40m
John and I have adapted the Stefan-Looptickle model of the 40m upgrade to have the parameters of the old one.
(old one = what we have had for the last 4 years).

Its in the /cvs/cds/caltech/iscmodeling directory on the CDS computers but you can also check it out from the
MIT CVS repo; its part of the whole shebang.

It makes the attached theoretical NB. Feel free to modify it.
Attachment 1: nb.png
14307   Mon Nov 19 22:01:50 2018 gautamUpdateVACLoose nut on valve

As I was turning off the lights in the VEA, I heard a rattling sound from near the PSL enclosure. I followed it to a valve - I couldn't see a label on this valve in my brief effort to find one, but it is on the south-west corner of the IMC table, so maybe VABSSCI or VABSSCO? The power cable is somehow spliced with an attachment that looks to be bringing gas in/out of the valve (See Attachment #1), and the nut on the bottom was loose, the whole power cable + mettal attachment was responsible for the rattling. I finger-tightened the nut and the sound went away.

Attachment 1: IMG_7171.JPG
11876   Fri Dec 11 23:12:09 2015 KojiSummaryCOCLoss map measurement document

Yutaro left detailed slides for his loss map measurement

https://dcc.ligo.org/LIGO-G1501547

11776   Tue Nov 17 20:40:08 2015 yutaroSummaryASCLoss maps of arm cavities

In preparation for the measurement of loss maps of arm cavities, I measured the relationship between:

the offset just after the demodulation of dithering loop (C1:ASS-YARM_ETM_PIT_L_DEMOD_I_OFFSET and C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET)

and

the angle of ETMY measured with oplev (C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON and C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON)

while the dithering script is running. With the angle of ETMY, we can calculate the beam spot on the ETMY assuming that the beam spot on the ITMY is not changed thanks to the dithering. What we have to do is to check the calbration of oplev with another way to measure the angle, to see if the results are reliable or not.

I will report the results later.

11779   Wed Nov 18 11:22:13 2015 yutaroUpdateASCLoss maps of arm cavities

I got linear relation between these. The results and method are below.

 Quote: In preparation for the measurement of loss maps of arm cavities, I measured the relationship between: the offset just after the demodulation of dithering loop (C1:ASS-YARM_ETM_PIT_L_DEMOD_I_OFFSET and C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET) and the angle of ETMY measured with oplev (C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON and C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON) while the dithering script is running. With the angle of ETMY, we can calculate the beam spot on the ETMY assuming that the beam spot on the ITMY is not changed thanks to the dithering. What we have to do is to check the calbration of oplev with another way to measure the angle, to see if the results are reliable or not. I will report the results later.

RESULTS

METHOD

I added offset (C1:ASS-YARM_ETM_PIT_L_DEMOD_I_OFFSET and C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET) to shift the beam spot on ETMY. For each data point, I measured the difference in angle of ETMY with oplev before and after adding offset. The precedure for each measurement I employed is following:

-- run dither

-- wait until error signals of dithering settle down

-- freeze dither

-- measure angle (10s avg)

-- wait until error signals of dithering settle down

-- freeze dither

-- measure angle (10s avg)

The reason why I measured the angle without offset for each measurement is that the angle which oplev shows changed with time (~several tens of minutes or something).

DISCUSSION

At the maximum values of offsets, the arm transmission power started to degrade, so the range where I can do this measurement is limited by these values as for now. However, we have to shift the beam spot more in order to make loss maps of sufficiently broad area on the mirror (the beam width (w) on ETM; w ~ 5 mm). Then, we have to find out how to shift the beam spot more.

Attachment 1: ETM_PIT_up.png
16253   Wed Jul 21 18:08:35 2021 yehonathanUpdateLoss MeasurementLoss measurement

{Gautam, Yehonathan, Anchal, Paco}

We prepared for the loss measurement using DC reflection method. We did the following changes:

1. REFL55_Q was disconnected and replaced with MC_T cable coming from the PD on the MC2 table. The cable has a red tag on it. Consequently we lost the AS beam. We realigned the optics and regained arm locks. The spot on the AS QPD had to be corrected.

2. We tried using AS55 as the PD for the DC measurement but we got ratios of ~ 0.97 which implies losses of more than 100 ppm. We decided to go with the traditional PD520 used for these measurements in the past.

3. We placed the PD520 used for loss measurements in front of the AS55 PD and optimized its position.

4. AS110 cable was disconnected from the PD and connected to PD520 to be used as the loss measurement cable.

5. In 1Y2 rack, AS110 PD cable was disconnected, REFL55_I was disconnected and AS110 cable was connected to REFL55_I channel.

So for the test, the MC transmission was measured at REFL55_Q and the AS DC was measured at REFL55_I.

We used the scripts/lossmap_scripts/armLoss/measArmLoss.py script. Note that this script assumes that you begin with the arm locked.

We are leaving the IFO in the configuration described above overnight and we plan to measure the XARM loss early AM. After which we shall restore the affected electrical and optical paths.

We ran the /scripts/lossmap_scripts/armLoss/measureArmLoss.py script in pianosa with 25 repetitions and a 30 s "duty cycle" (wait time) for the Y arm. Preliminary results give an estimated individual arm loss of ~ 30 ppm (on both X/Y arms) but we will provide a better estimate with this measurement.

16254   Thu Jul 22 16:06:10 2021 PacoUpdateLoss MeasurementLoss measurement

[yehonathan, anchal, paco, gautam]

We concluded estimating the XARM and YARM losses. The hardware configuration from yesterday remains, but we repeated the measurements because we realized our REFL55_I_ERR and REFL55_Q_ERR signals representing the PD520 and MC_TRANS were scaled, offset, and rotated in a way that wasn't trivially undone by our postprocessing scripts... Another caveat that we encountered today was the need to add a "macroscopic" misalignment to the ITMs when doing the measurement to avoid any accidental resonances.

The final measurements were done with 16 repetitions, 30 second duration, and the logfiles are under scripts/lossmap_scripts/armLoss/logs/20210722_1423.txt and scripts/lossmap_scripts/armLoss/logs/20210722_1513.txt

Finally, the estimated YARM loss is 39$\pm$7 ppm, while the estimated XARM loss is 38$\pm$8 ppm. This is consistent with the inferred PRC gain from Monday and a PRM loss of ~ 2%.

Future measurements may want to look into slow drift of the locked vs misaligned traces (systematic errors?) and a better way of estimating the statistical uncertainty (e.g. by splitting the raw time traces into short segments)

16256   Sun Jul 25 20:41:47 2021 ranaUpdateLoss MeasurementLoss measurement

What are the quantitative root causes for why the statistical uncertainty is so large? Its larger than 1/sqrt(N)

16257   Mon Jul 26 17:34:23 2021 PacoUpdateLoss MeasurementLoss measurement

[gautam, yehonathan, paco]

We went back to the loss data from last week and more carefully estimated the ARM loss uncertainties.

Before we simply stitched all N=16 repetitions into a single time-series and computed the loss: e.g. see Attachment 1 for such a YARM loss data. The mean and stdev for this long time series give the quoted loss from last time. We knew that the uncertainty was most certainly overestimated, as different realizations need not sample similar alignment conditions and are sensitive to different imperfections (e.g. beam angular motion, unnormalizable power fluctuations, etc...).

Today we analyzed the individual locked/misaligned cycles individually. From each cycle, it is possible to obtain a mean value of the loss as well as a std dev *across the duration of the trace*, but because we have a measurement ensemble, it is also possible to obtain an ensemble averaged mean and a statistical uncertainty estimate *across the independent cycle realizations*. While the mean values don't change much, in the latter estimate we find a much smaller statistical uncertainty. We obtain an XARM loss of 37.6 $\pm$ 2.6 ppm and a YARM loss of 38.9 $\pm$ 0.6 ppm. To make the distinction more clear, Attachment 2 and  Attachment 3 the YARM and XARM loss measurement ensembles respectively with single realization (time-series) standard deviations as vertical error bars, and the 1 sigma statistical uncertainty estimate filled color band. Note that the XARM loss drifts across different realizations (which happen to be ordered in time), which we think arise from inconsistent ASS dither alignment convergence. This is yet to be tested.

For budgeting the excessive uncertainties from a single locked/misaligned cycle, we could look at beam pointing, angular drift, power, and systematic differences in the paths from both reflection signals. We should be able to estimate the power fluctuations by looking at the recorded arm transmissions, the recorded MC transmission, PD technical noise, etc... and we might be able to correlate recorded oplev signals with the reflection data to identify angular drift. We have not done this yet.

Attachment 1: LossMeasurement_RawData.pdf
Attachment 2: YARM_loss_stats.pdf
Attachment 3: XARM_loss_stats.pdf
14815   Mon Jul 29 13:32:56 2019 gautamUpdateLoss MeasurementLoss measurement PD installed in AS path

[yehonathan, gautam]

• we placed a PDA520 photodiode in the AS beampath, so AS110 and AS55 no longer see any light.
• ITMX and ETMX were misaligned (since the plan is to measure the Y arm loss).
• The PDA520 and MC2 transmission are currently going to the Y arm ALS beat channels in the DAQ system. Unfortunately, we have no control over the whitening gains for these channels because of the c1iscaux2 situation.
14448   Mon Feb 11 19:53:59 2019 gautamSummaryLoss MeasurementLoss measurement setup

To measure the Y-arm loss, I decided to start with the classic reflectivity method. To prepare for this measurement, I did the following:

1. Placed a PDA 520 in the AS beam path on the AS table.
2. Centered AS beam on above PDA 520.
3. Monitored signal from PDA520 and the MC transmission simultaneously in the single-bounce from ITMY config (i.e. all other optics were misaligned). Convinced myself that variations in the two signals were correlated, thus ruling out in this rough test any interference from ghost beams from ITMX / PRM etc.
4. For the DAQ, I decided to use the two ALS Y arm channels in 1Y4, mainly because we have some whitening electronics available there - the OMC model would've been ideal but we don't have free whitening channels available there. So I ran long BNCs to the rack, labelled them.
5. It'd be nice to have these signals logged to frames, so I added DQ-channels for the IN1 points of the BEATY_FINE filters, recording at 2048 Hz for now. Of course this necessitated restart of the c1lsc model, which caused all the vertex FEs to crash, but the reboot script brought everything back smoothly.
6. Not sure what to make of the shape of the spectrum of the AS photodiode, see Attachment #1 - looks like some kind of scattering shelf but I checked the centering on the PD itself, looks good. In any case, with the whitening gains I'm using, seems like both channels are measuring above ADC noise.
7. Found that the existing misalignment to the ETMY does not eliminate signatures of cavity flash in the AS photodiode. So I increased the amount of misalignment until I saw no evidence of flashes in the reflected photodiode.
8. Johannes' old scripts didn't work out of the box - so I massaged it into a form that works.
9. Re-centered Oplevs to try and keep them as well centered in the linear range as possible, maybe the DC position info from the Oplevs is useful in the analysis.

I'm running a measurement tonight, starting now (~1130PM), should be done in ~1hour, may need to do more data-quality improvements to get a realistic loss number, but I figured I'd give this a whirl.

I'm rather pleased with an initial look at the first align/misalign cycle, at least there is discernable contrast between the two states - Attachment #2. The data is normalized by MC transmission, and then sig.decimated by x512 (8**3).

Attachment 1: DQcheck.pdf
Attachment 2: initialData.pdf
14449   Tue Feb 12 18:00:32 2019 gautamSummaryLoss MeasurementLoss measurement setup

Another arm loss measurement started at 6pm.

13235   Mon Aug 21 20:11:25 2017 johannesSummaryGeneralLoss measurements plan

There are three methods we (will soon) have available to evaluate the round-trip dissipative losses in the arms that do not suffer from the ITM loss dominance:

• DC reflection method:
• Compare reflected light levels from [ITM only] vs [arm cavity on resonance]
• Basler CCDs:
• Infer large (or small) angle scatter loss with calibrated CCDs
• Reflection ringdowns:
• Need AS port light injection, principle is similar to DC method but better (?)

### DCREFL

The DC method comparing reflectivities has been used in the past and is relatively easy to do. After the recent vacuum troubles the first step should be to re-perform these as CDS permits (needs some ASS functionality and of course the MC to behave). It wouldn't hurt to know the parameters this depends on, aka mode overlap and modulation depths with better certainty. Maybe the SURF scripts for mode-spectroscopy can be applied?

### CCDs

With the new CCD cameras calibrated, pre-vent we can determine the magnitude of the large-angle scatter loss (assuming isotropic scatter) of ETMX and possibly ETMY. Can we look past ETMX/ETMY from the viewports? Then we can probably also look at the small angle scatter of ITMX and ITMY. If not, once we open one of the chambers there's the option of installing mirrors as close as possible to the main beam path. The easiest is probably to look at ITMX, since there is plenty of space in the XEND chamber, and the camera is already installed.

### ASPORT

This requires a lot of up-front work. We decided to use the spare 200mW NPRO. It will be placed on the PSL table and injected into an optical fiber, which terminates on the AS table. The again free space beam there needs to be sort-of mode-matched into the SRC ("sort-of" because mode-spectroscopy). We want to be able to phaselock this secondary beam to the PSL with at least a couple kHz bandwidth and also completely extinguish the beam on time-scales of a few microseconds. We will likely need to purchase a few components that we can salvage from other labs, I'm still going through the inventory and will know more soon (more detailed post to follow). We need to settle for the polarization we want to send in from the back.

## Tentative Schedule (aggressive)

#### Week Aug 21 - Aug 27:

• Update mode-overlap estimates
• Obtain current DC refl estimates
• Spatial profile of auxiliary NPRO
• CCD software prep work

#### Week Aug 28 - Sep 3:

• Re-evaluate modulation indices if necessary
• Optical beat AS Port Auxiliary Laser (ASAL) - PSL
• PLL setup
• CCD large angle prep work

#### Week Sep 4 - Sep 10:

• PLL CDS integration
• Amplitude-modulation preparation
• CCD large angles

#### Week Sep 11 - Sep 17:

• Fiber-injection
• AS table preliminary mode-matching
• CCD small angle prep work

#### Week Sep 18 - Sep 24:

• ASAL amplitude switching
• CCD small angles

#### Week Sep 25 - Oct 1:

• AS port ringdowns

13236   Mon Aug 21 21:26:41 2017 gautamSummaryGeneralLoss measurements plan

In case you want to use it, I had profiled the Lightwave NPRO sometime back, and we were even using it as the AUX X laser for a short period of time.

As for using the AS laser for mode spectroscopy: don't we want to match the beam into the cavity as best as possible, and then use some technique to disturb the input mode (like the dental tooth scraper technique from Chris Mueller's thesis)?

Johannes and I did an arm scan of the X arm today (arm controlled with ALS, monitoring IR transmission) - only 2 IR FSRs were scanned, but there should be sufficient information in there to extract the modulation depth and mode matching - can we use Kaustubh's/Naomi's code?. The Y arm ALS needs to be touched up so I don't have a Y arm scan yet. Note that to get a good arm scan measurement, the High Gain Thorlabs PD should be used as the transmission PD.

Quote:

#### Week Aug 21 - Aug 27:

• Update mode-overlap estimates
• Obtain current DC refl estimates
• Spatial profile of auxiliary NPRO
• CCD software prep work

9014   Thu Aug 15 12:30:17 2013 manasaUpdateGreen LockingLost beat notes

[Koji, Nic, Manasa]

Update from last night.

Koji and I realigned the green optics on the PSL to start working on the ALS.

We set on a beat note search. We couldn't find the beat note between any of the arm green transmission and the PSL green. All we could see was the beat between the X arm and the Y arm green leakage.

Since we had the beatnote between the 2 green transmission beams, we decided to scan the PSl temperature. We scanned the SLOW actuator adjust of PSL; but couldn't locate any beat note. The search will continue again today.

27   Mon Oct 29 23:10:05 2007 waldmanConfigurationOMCLost in DAQspace
[Pinkesh, Sam]

In setting up a Digital based control of the hanging OMC, we naively connect the Anti-Imaging filter output to an Anti-Aliasing input. This led to no end of hell. For one thing, we found the 10 kHz 3rd order butterworth at 10 kHz, where it should be based on the install hardware. One wonders in passing whether we want a 10 kHz butter instead of a 15 kHz something else, but I leave that for a later discussion. Much more bothersome is a linear phase shift between output and input that looks like ~180 microseconds. It screams "What the hell am I!?" and none of us could scream back at it with an answer. I believe this will require the Wilson House Ghost Busters to fully remedy on the morrow.
Attachment 1: SS.pdf
Attachment 2: SS.gif
6097   Fri Dec 9 17:08:41 2011 JenneUpdateRF SystemLots of current used in Rich's demod box

I checked the power regulators on the Rich demod box (according to the schematic, D1000217).  The positive one is LM2941CT, and the negative one is LM2991T.  Both accept input voltage up to +26V or -26V respectively.  So my use of +\- 24V to be regulated down to +\- 15V isn't too crazy.  It's a little crazy, but not too crazy.  They recommend having only a 3V difference between the input and output voltages.  We don't have any 18V or 20V power supplies in the regular LSC power supply rack, so Rana suggested using the 24's.

When I plug in and turn on the Rich box, the current on the +24V power supply goes up by about 0.8A, and the -24V supply goes up by about 0.3A.  That seems like kind of a lot.  Is that too much?  Do I need to find a better plan that involves +\- 18V?  Thoughts?

For now, the Rich box is off, just in case.

6099   Fri Dec 9 17:44:45 2011 KojiUpdateRF SystemLots of current used in Rich's demod box

Those asymmetric currents are same as what I saw with the table top +/-18V supply. If you really don't like it, there could be an option to disconnect CH3/4 in the box.

In any case, this could be a good long-run test of the demod box, couldn't it?

 Quote: I checked the power regulators on the Rich demod box (according to the schematic, D1000217).  The positive one is LM2941CT, and the negative one is LM2991T.  Both accept input voltage up to +26V or -26V respectively.  So my use of +\- 24V to be regulated down to +\- 15V isn't too crazy.  It's a little crazy, but not too crazy.  They recommend having only a 3V difference between the input and output voltages.  We don't have any 18V or 20V power supplies in the regular LSC power supply rack, so Rana suggested using the 24's.  When I plug in and turn on the Rich box, the current on the +24V power supply goes up by about 0.8A, and the -24V supply goes up by about 0.3A.  That seems like kind of a lot.  Is that too much?  Do I need to find a better plan that involves +\- 18V?  Thoughts? For now, the Rich box is off, just in case.

6101   Fri Dec 9 20:03:57 2011 ZachUpdateRF SystemLots of current used in Rich's demod box

D0902745-v5 (probably the AP1053's):

Quote:

Those asymmetric currents are same as what I saw with the table top +/-18V supply. If you really don't like it, there could be an option to disconnect CH3/4 in the box.

In any case, this could be a good long-run test of the demod box, couldn't it?

 Quote: I checked the power regulators on the Rich demod box (according to the schematic, D1000217).  The positive one is LM2941CT, and the negative one is LM2991T.  Both accept input voltage up to +26V or -26V respectively.  So my use of +\- 24V to be regulated down to +\- 15V isn't too crazy.  It's a little crazy, but not too crazy.  They recommend having only a 3V difference between the input and output voltages.  We don't have any 18V or 20V power supplies in the regular LSC power supply rack, so Rana suggested using the 24's.  When I plug in and turn on the Rich box, the current on the +24V power supply goes up by about 0.8A, and the -24V supply goes up by about 0.3A.  That seems like kind of a lot.  Is that too much?  Do I need to find a better plan that involves +\- 18V?  Thoughts? For now, the Rich box is off, just in case.

7552   Mon Oct 15 22:24:45 2012 JenneUpdateComputersLots of new White :(

Evan and I are starting to lock, and there is lots of new, unfortunate white stuff on several different screens.

C1:TIM-PACIFIC_STRING is gone, C1:IFO-STATE (MC state) is gone, C1:LSC-PZT..._requests are gone (all 4 of them), C1:PSL-FSS_FASTSWEEPTEST from the FSS screen is gone (although I'm not sure that that one is newly gone), lots of the WF AA lights on the LSC screen are gone.

Those are the things I find in a few minutes of not really looking around.

EDIT:  IPPOS is also gone, so I can't see how my current alignment relates to old alignments.

13464   Thu Dec 7 11:14:37 2017 johannesHowToComputer Scripts / ProgramsLots of red on the FE status screen

Since we're getting ready to put the replacement slow DAQ for c1auxex in I wanted to bring the IFO back to operating condition after the PMC hasn't been locked for days. Something seems wrong with the CDS system though, many of the frontent models have red background and don't seem to be responsive. I followed the instructions laid out in https://wiki-40m.ligo.caltech.edu/Computer_Restart_Procedures.

In the attached screenshot, initially all c1ioo models were red, and on c1iscex only c1x01 was blue, the other ones red. I was able to ssh into both machines and tried to restart indivitual models, which didn't work and instead turned their background white. Still following the wiki page, I restarted both machines but they don't respond to pinging anymore and thus I cannot use ssh to reach them. Not sure what to do, I also rebooted fb over telnet.

So far I couldn't find any records of how to fix this situation.

Attachment 1: 22.png
13465   Thu Dec 7 15:02:37 2017 KojiHowToComputer Scripts / ProgramsLots of red on the FE status screen

Once a realtime machine was rebooted, it did not come back. I suspect that the diskless hosts have a difficulty to boot up.

Attachment 1: DSC_0552.JPG
13466   Thu Dec 7 15:46:31 2017 johannesHowToComputer Scripts / ProgramsLots of red on the FE status screen

[Koji, Johannes]

The issue was partially fixed and the interferometer is in workable condition now.

What -probably- fixed it was restarting the dhcp server on chiara

sudo service isc-dhcp-server restart

Afterwards the frontends were restarted one by one. SSH access was possible and the essential models for IFO operation were started.

c1iscex reported initially that no DAQ card was found, and inside the IO chassis the LED indicator strip was red. Turning off the machine, checking the cables and rebooting fixed this.

Attachment 1: 04.png
13467   Thu Dec 7 16:28:06 2017 KojiUpdateIOOLots of red on the FE status screen

Once the RT machines were back, we launched only the five IOPs. They had bunch of red lights, but we continued to run essential models for the IFO. SOme of the lights were fixed by "global diag reset" and "mxstream restart".

The suspension were damped. We could restore the IMC lock. The locking became OK and the IMC was aligned. The REFL spot came back.

At least, I could confirm that the WFS ASC signals were not transmitted to c1mcs. There must be some disconneted links of IPC.

13474   Thu Dec 14 07:07:09 2017 ranaUpdateIOOLots of red on the FE status screen

I had to key the c1psl crate to get the PMC locking again. Without this, it would still sort of lock, but it was very hard to turn on the loop; it would push itself off the fringe. So probably it was stuck in some state with the gain wrong. Since the RF stuff is now done in a separate electronics chain, I don't think the RF phase can be changed by this. Probably the sliders are just not effective until power cycling.

 Quote: Once the RT machines were back, we launched only the five IOPs. They had bunch of red lights, but we continued to run essential models for the IFO. SOme of the lights were fixed by "global diag reset" and "mxstream restart". The suspension were damped. We could restore the IMC lock. The locking became OK and the IMC was aligned. The REFL spot came back. At least, I could confirm that the WFS ASC signals were not transmitted to c1mcs. There must be some disconneted links of IPC.

I then tried to get the MC WFS back, but running rtcds restart --all would make some of the computers hang. For c1ioo I had to push the reset button on the computer and then did 'rtcds start --all' after it came up. Still missing IPC connections.

I'm going to get in touch with Rolf.

4329   Sat Feb 19 01:58:20 2011 ranaSummaryElectronicsLow Noise BJT Pre-Amp

Frank put his low noise preamp info here.

I suggest that we build these (using Altium) but replace the cheapo transistors with the high class MAT03 matched BJT pair from Analog Devices.

This will allow us to have a pre-amp better matched to the noise of the mixers down to low frequency.

13291   Tue Sep 5 02:07:49 2017 gautamUpdateLSCLow Noise DRMI attempt

## Summary:

Tonight, I was able to lock the DRMI, turn on the whitening filters for the sensing PDs, and also turn on the coil de-whitening filters for ITMX, ITMY and BS. However, I didn't see the expected improvement in the MICH spectrum between ~50-300 Hz . Sad.

## Details:

I basically went through the list of tasks I made in the previous elog. Some notes:

• The UGF servos suggested that I had to lower the SRCL gain. I lowered it from -0.055 to -0.025. OLTF measurement using In1/In2 method suggested UGF ~120Hz. I don't know why this should be. Plot to be uploaded later.
• Since we aren't actuating on the ITMs, I was able to leave their coils de-whitened all the time.
• For the BS, it was trickier - I had to play around a little with the "Tolerance" setting in Foton while looking at transients (using DTT, not a scope for now) while switching the filters.
• This transition isn't so robust yet - but eventually I found a setting that worked, and I was able to successfully turn on the de-whitening thrice tonight (but also failed about the same number of times). [GV Oct 6 2017: Remember that the PD whitening has to be turned on for this transition to be successful - otherwise the RMS from the high frequencies saturate the DAC.]
• The locks were pretty stable. One was ~10mins, one was ~15mins, and I broke both deliberately because I was out of ideas as to why the part of the MICH error signal spectrum that I thought was due to DAC noise didn't improve.
• I've made a bunch of shell scripts to help with the various switchings - but now that I think of it, I should make these python scripts.

Attachment #1: Comparison of MICH_ERR with and without the BS de-whitening. Note that the two ITMs have their coils de-whitened in both sets of traces.

Attachment #2: Spectra of MICH output and one of the BS coil outputs in both states. The DAC RMS increases by ~30x when the de-whitening is engaged, but is still well within limits.

So it looks like the switching of paths is happening correctly. The "CDS BIO STATUS" MEDM screen also shows the appropriate bits toggling when I turn the de-whitening on/off. There is no broadband coherence with MCF between 50-300 Hz so it seems unlikely that this could be frequency noise.

Clearly I am missing something. But anyways I have a good amount of data, may be useful to put together the post CDS/electronics modification DRMI noise budget. More analysis to follow.

Attachment 1: MICH_err_comp.pdf
Attachment 2: deWhitenedCoil.pdf
3040   Wed Jun 2 22:25:39 2010 KevinUpdatePSLLow Power 2W Beam Profile

Koji is worried about thermal lensing introducing errors to the measurement of the 2W beam profile so I measured the profile at a lower power.

I used the same setup and methods used to measure the profile at 2W (see entry). This measurement was taken with an injection current of 1.202 A and a laser crystal temperature of 25.05° C. This corresponds to approximately 600 mW (see power measurement).

The data was fit to  w = sqrt(w0^2+lambda^2*(x-x0)^2/(pi*w0)^2) with the following results

For the horizontal beam profile:

reduced chi^2 = 2.7

x0 = (-203 ± 3) mm

w0 = (151.3 ± 1.0) µm

For the vertical beam profile:

reduced chi^2 = 6.8

x0 = (-223 ± 6) mm

w0 = (167.5 ± 2.2) µm

In the following plots, the blue curve is the fit to the vertical beam radius, the purple curve is the fit to the horizontal beam radius, * denotes a data point from the vertical data, and + denotes a data point from the horizontal data.

The differences between the beam radii for the low power and high power measurements are

Δw0_horizontal = (38.3 ± 1.2) µm

Δw0_vertical = (43.5 ± 2.4) µm

Thus, the two measurements are not consistent. To determine if the thermal lensing is in the laser itself or due to reflection from the W2 and mirror, we should measure the beam profile again at 2W with a razor blade just before the W2 and a photodiode to measure the intensity of the reflection off of the front surface. If this measurement is consistent with the measurement made with the beam scan, this would suggest that the thermal lensing is in the laser itself and that there are no effects due to reflection from the W2 and mirror. If the measurement is not consistent, we should do the same measurement at low power to compare with the measurement described in this entry.

 

Attachment 1: profile_low.png
11611   Thu Sep 17 13:06:05 2015 ericqSummaryLSCLow input impedance on CM board

As it turns out, our version of the common mode board does not have high input impedence. I think this is what is messing with the lowpass.

I added photos of the PCB to our 40m DCC page about this board: D1500308, wherein you can see that we have Revision B.

On the aLIGO wiki's CommonModeServo page, one finds that high input impedence was added in Revision E. At LIGO-D040180, one finds this was implemented via an additional dual AD829 instrumentation amplifier stage before the input amplification stage that exists on our board.

Also, I find that the boosts installed are the default 40:4k, 1k:20k, 1k:20k, 500:10k pole zero pairs. Given our 30-40kHz UGF for CARM thus far, maybe we would like to lower some of these boost corner frequencies, to actually be able to use them; so far we only use the first two.

14129   Fri Aug 3 15:53:25 2018 gautamUpdateSUSLow noise bias path idea

Summary:

The idea we are going with to push the coil driver noise contribution down is to simply increase the series resistance between the coil driver board output and the OSEM coil. But there are two paths, one for fast actuation and one that provides a DC current for global alignment. I think the simplest way to reduce the noise contribution of the latter, while preserving reasonable actuation range, is to implement a precision DC high-voltage source. A candidate that I pulled off an LT application note is shown in Attachment #1.

Requirements:

• The series resistance in the bias path should be $10 k\Omega$, such that the noise from this stage is dominated by the Johnson noise of said resistor, and hence, the current noise contribution is negligible compared to the series resistance in the fast actuation path ($4.5 k\Omega$).
• Since we only really need this for the test masses, what actuation range do we want?
• Currently, ETMY has a series resistance of $400\Omega$ and has a pitch DC bias voltage of -4 V.
• This corresponds to 10 mA of DC current.
• To drive this current through $10 k\Omega$, we need 100 V.
• I'm assuming we can manually correct for yaw misalignments such that 10mA of DC current will be sufficient for any sort of corrective alignment.
• So +/- 120 V DC should be sufficient.
• The current noise of this stage should be negligible at 100 Hz.
• The noise of the transistors and the HV supply should be suppressed by the feedback loop and so shouldn't be a significant contribution (I'll model to confirm).
• The input noise of the LT1055 is ~20nV/rtHz at 100 Hz, while the Johnson noise of $10 k\Omega$ is ~13nV/rtHz so maybe the low-passing needs to be tuned, but I think if it comes to it, we can implement a passive RC network at the output to achieve additional filtering.
• To implement this circuit, we need +/- 125V DC.
• At EX and EY, we have a KEPCO HV supply meant to be used for the Green Steering PZTs.
• I'm not sure if these can do bipolar outputs, if not, for temporary testing, we can transport the unit at EY to EX.

If all this seems reasonable, I'd like to prototype this circuit and test it with ETMX, which already has the high series resistance for the fast path. So I will ask Steve to order the OpAmp and transistors.

Attachment 1: LT1055_precOpAmp.pdf
14130   Fri Aug 3 16:27:40 2018 ranaUpdateSUSLow noise bias path idea

Bah! Too complex.

11226   Mon Apr 20 16:18:29 2015 JenneUpdateElectronicsLow noise pre-amps: returned

The Rai box was in the Cryo lab, and the Busby box was in the TCS lab.  Neither had been signed out.  Lame.  Anyhow, thanks to Evan and Zach's memories of having seen them recently, they have been returned to the 40m where they belong.  (Also, I grabbed a spare Marconi while I was over there, for the phase noise measurement).

11228   Mon Apr 20 21:26:46 2015 ranaUpdateElectronicsLow noise pre-amps: returned

+1 to both Evan and Zach for prompt info and +2 to you for getting more stuff than you started looking for. -2 karma to whomever had swiped them and hoarded without signing. You should put a 40m sticker on both of them. Make sure to check / use fresh batteries. The Busby box is BJT based and works on low impedance sources, the Rai box works on anything, but (I am guessing) has less CMRR.

 Quote: The Rai box was in the Cryo lab, and the Busby box was in the TCS lab.  Neither had been signed out.  Lame.  Anyhow, thanks to Evan and Zach's memories of having seen them recently, they have been returned to the 40m where they belong.  (Also, I grabbed a spare Marconi while I was over there, for the phase noise measurement).

11225   Sun Apr 19 15:03:26 2015 JenneUpdateElectronicsLow noise pre-amps?

Does anyone know where the Busby or Rai low noise pre-amp boxes are?

I think I need one in order to measure the noise of the Marconi.  Right now, I am trying to measure the amplitude noise, but I'm not seeing anything on the SR785 above the analyzer's noise level.

4456   Tue Mar 29 15:01:58 2011 Larisa ThorneUpdateElectronicsLow pass filter for X arm laser temperature control

This is the continuation of http://nodus.ligo.caltech.edu:8080/40m/4402

The first picture is of the actual component, where the resistor is 1M and capacitor is 10uF.

But before the component can be put into place, its transfer function had to be checked to make sure it was doing what we calculated it would do. The results of these are in the graphs generated: frequency vs. gain, and frequency vs. phase.

According to these graphs, we are not achieving the targeted cutoff frequency: need to recalculate and compensate for the extra 100k resistance being encountered.

Attachment 1: DSC_2889.JPG
Attachment 2: LPFgraph.pdf
4457   Tue Mar 29 15:50:21 2011 KojiUpdateElectronicsLow pass filter for X arm laser temperature control

For bode plot:

USE LOG-LOG plot for the amplitude

USE LOG-LINEAR plot for the phase

Search "Bode Plot" on web

4531   Fri Apr 15 13:40:00 2011 Larisa ThorneUpdateElectronicsLow pass filter for X arm laser temperature control, second try

Plotting the data points yielded by the spec analyzer of my first LPF yielded a result that was not expected: the desired cutoff frequency wasn't achieved because of some extra 100k resistance that wasn't taken into consideration. (see  here ). I have redrawn the Bode graphs for this configuration so that it is easier to see that it is wrong (first attachment)

After some calculation adjustments, it was found that the capacitor value could remain at 10uF, but the resistance needed to be changed to 100k to maintain a gain of 0.5 and critical frequency at 0.1Hz. Second attachment is the Bode graph that results from this configuration.

Note: Bode graphs are both in Log-Linear scales (Wikipedia said so)

Attachment 1: Bode2.jpeg
Attachment 2: Bode100k.jpg
14068   Fri Jul 13 18:01:13 2018 gautamUpdateGeneralLow power MC

After getting the go ahead from Steve, I removed the physical beam block on the PSL table, sent the beam into the IFO, and re-aligned the MC to lock at low power. I've also revived my low power autolocker (running on megatron), seems to work okay though the gains may not be optimal, but it seems to do the job for now. Nominal transmission when well aligned at low power is ~1200cts. I briefly checked Y arm alignment with the green, seems okay, but didn't try locking the Y arm yet. All doors are still on, and I'm closing the PSL shutter again while Keerthana and Sandrine are working near the AS table.

1346   Mon Mar 2 21:16:32 2009 YoichiUpdateLockingLow-gain High-gain PD switching may not be working well
Osamu, Yoichi

This afternoon, I run the locking script while doing calculations for the upgrade.
The IFO lost lock even at lower arm powers (around 6) if it was operated for a while (~ 5min).
It seemed as if there were some intermittent glitches (seismic? laser?) causing the lock losses.
We also saw once the TRX and TRY signals saturated at around arm power = 11 when there was a large fluctuation in the arm power.
Osamu suggested that it looked like the high-gain to low-gain PD switching was not working.

I won't come tonight as I may have caught a cold, but if someone comes tonight, it is worth checking the PD switching.
1350   Tue Mar 3 19:26:44 2009 YoichiUpdateLockingLow-gain High-gain PD switching may not be working well
I checked the switching of the QPDX from high gain to low gain.
Switching happens as expected, but the low gain QPDX output was very low compared to QPDY.
Also the digital gain for the high gain TRX was not matched with the low gain one. So when the switching happens, there is a large jump in the TRX.

I also found that the offset values for the low gain QPDX were totally wrong. I adjusted it.
Then I removed a beam splitter in front of the QPDX to increase the power falling on it.
But still the low gain QPDX output is four times lower than the low gain QPDY.

I'm still working on it. So don't expect the switching to work correctly at this moment.
I'm planning to be back after the dinner.

 Quote: Osamu, Yoichi This afternoon, I run the locking script while doing calculations for the upgrade. The IFO lost lock even at lower arm powers (around 6) if it was operated for a while (~ 5min). It seemed as if there were some intermittent glitches (seismic? laser?) causing the lock losses. We also saw once the TRX and TRY signals saturated at around arm power = 11 when there was a large fluctuation in the arm power. Osamu suggested that it looked like the high-gain to low-gain PD switching was not working. I won't come tonight as I may have caught a cold, but if someone comes tonight, it is worth checking the PD switching.
1351   Tue Mar 3 23:59:26 2009 YoichiUpdateLockingLow-gain High-gain PD switching may not be working well

 Quote: I checked the switching of the QPDX from high gain to low gain. Switching happens as expected, but the low gain QPDX output was very low compared to QPDY. Also the digital gain for the high gain TRX was not matched with the low gain one. So when the switching happens, there is a large jump in the TRX. I also found that the offset values for the low gain QPDX were totally wrong. I adjusted it. Then I removed a beam splitter in front of the QPDX to increase the power falling on it. But still the low gain QPDX output is four times lower than the low gain QPDY. I'm still working on it. So don't expect the switching to work correctly at this moment. I'm planning to be back after the dinner.

This sounds like the QPD whitening gain sliders may be stuck. The slider twiddling script should be run, or the sliders should be twiddled by hand.
1352   Wed Mar 4 03:37:51 2009 YoichiUpdateLockingLow-gain High-gain PD switching may not be working well

 Quote: This sounds like the QPD whitening gain sliders may be stuck. The slider twiddling script should be run, or the sliders should be twiddled by hand.

Yes, it was indeed the whitening gain slider problem.
I moved them and the QPDX gain went up suddenly. I reinstalled the BS in front of the QPDX and adjusted the offsets, gains accordingly.
Now the high-gain to low-gain switching is fine.
13424   Fri Nov 10 13:46:26 2017 SteveUpdatePEMM3.1 local earthquake

BOOM SHAKA-LAKA

Attachment 1: 3.1M_local_EQ.png
15580   Sat Sep 19 01:49:52 2020 KojiUpdateGeneralM4.5 EQ in LA

M4.5 EQ in LA 2020-09-19 06:38:46 (UTC) / -1d 23:38:46 (PDT) https://earthquake.usgs.gov/earthquakes/eventpage/ci38695658/executive

I only checked the watchdogs. All watchdogs were tripped. ITMX and ETMY seemed stuck (or have the OSEM magnet issue). They were left tripped. The watchdogs for the other SUSs were reloaded.

15581   Sat Sep 19 11:27:04 2020 ranaUpdateGeneralM4.5 EQ in LA

the seismometers obviously saturated during the EQ, but the accelerometers captured some of it. It looks like there's different saturation levels on different sensors.

Also, it seems the mounting of the MC2 accelerometers is not so good. There's some ~10-20 Hz resonance its mount that's showing up. Either its the MC2 chamber legs or the accelerometers are clamped poorly to the MC2 baseplate.

Sun Sep 20 00:02:36 2020 edit: fixed indexing error in plots

* also assuming that the sensors are correctly calibrated in the front end to 1 count = 1 um/s^2 (this is what's used in the summ pages)

Attachment 1: Sep18-EQ.pdf
15583   Sat Sep 19 18:08:34 2020 ranaUpdateGeneralM4.5 EQ in LA

the EQ was ~14 km south of Caltech and 17 km deep

 Quote: the seismometers obviously saturated during the EQ, but the accelerometers captured some of it. It looks like there's different saturation levels on different sensors. Also, it seems the mounting of the MC2 accelerometers is not so good. There's some ~10-20 Hz resonance its mount that's showing up. Either its the MC2 chamber legs or the accelerometers are clamped poorly to the MC2 baseplate.

I'm amazed at how much higher the noise is on the MC2 accelerometer. Is that really how much amplification of the ground motion we're getting? If so, its as if the MC has no vibration isolation from the ground in that band. We should put one set on the ground and make the more direct comparison of the spectra. Also, perhaps do some seismic FF using this sensor - I'm not sure how successful we've been in this band.

Attaching the coherence plot from ldvw.ligo.caltech.edu (apparently it has access to the 40m data, so we can use that as an alternative to dtt or python for remote analysis):

It would be interesting to see if we can use the ML based FF technology from this summer's SURF project by Nadia to increase the coherence by including some slow IMC alignment channels.

ELOG V3.1.3-