40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 83 of 344 Not logged in
ID Date Author Type Category Subject
3802   Thu Oct 28 02:01:51 2010 KevinUpdatePSLFilter for 2W Laser

[Rana and Kevin]

I made a low pass filter for the piezo driver for the 2W laser that is now installed. The filter has a pole at 2.9 Hz. The transfer function is shown in attachment 1.

Attachment 2 shows the outside of the filter with the circuit diagram and attachment 2 shows the inside of the filter.

3707   Wed Oct 13 17:12:33 2010 josephb, yutaUpdateCDSFilter name length problem found and fixed

The missing filter files for ULPOS, URPOS, and so forth for the mode cleaner optics was due to the length of the names of the filters.

This was not a problem for the c1sus model because it was using its own name as the first 3 letters of its designation.  A filter for the sus model would be called something like BS_TO_COIL_MTRX_0_0, while for the mcs it would be called SUS_MC1_TO_COIL_MTRX_0_0, an extra 4 characters.

However, the c1mcs model used the "top_name" feature which uses a subsystem box within the simlink model to rename all the channels.  Apparently in the filter file, this means it has to add the top name to the front of everything, adding an additional 3 characters.  This pushed things over the length limit.

A hard cap of 18 characters has been added to the FiltMuxMatrix.pm file (located in /cvs/cds/caltech/c1/, so that it will prevent this type of problem in the future by stopping at compile time and presenting a helpful error message.

I also fixed a bug with too many spaces in the feCodeGen.pl file when dealing with top_names and the filtMuxMatrix.pm preventing some .adl files from being generated.

Also of interest, MC3 appears to never have had F2A filters.  For the moment we're running without them, but since they're just a fine tuning it shouldn't affect locking tonight.

Improbability factor of mode cleaner suspensions working tonight: ~20

995   Fri Sep 26 00:19:54 2008 JenneUpdatePSLFilter-action with the PMC
Written, but not posted on 24Sept2008:

Today's mission was to make more progress on increasing the bandwidth of the PMC servo.

First order of business was to improve the performance of the 14.6kHz notch that Rana put in the PMC servo board a few weeks ago to remove the 14.6kHz body mode resonance of the PMC. Looking at the zoomed in TF that I posted Monday (elog #978), we see that there is still a remnant of a peak near 14.5kHz. A first gut-reaction is that the notch is not tuned properly, that we have just missed the peak. As previously noted in the elog, the peak that we are trying to notch out is at 14.68kHz (elog #874). By unlocking the PMC and measuring the transfer function between FP2 and OutMon (OutMon is the monitor for the high voltage going to the PMC's PZT), I measure the transfer function of the notch, and find that it is notching at 14.63kHz. So we're a teensy bit off, but the Q of the notch is such that we're still getting improvement at the peak frequency. After checking that we are hitting the correct frequency, I put a short (just some wire) around R21, which is the R in the RLC notch filter, to increase the depth of the notch. At the peak frequency of 14.68kHz, we see a 2.5dB improvement of the notch. At the actual notch frequency of 14.63kHz, we see a 3.2dB increase in the depth of the notch. So, shorting R21 helped a little, but not a lot. Also, it's clear that we don't get that much more improvement by being on the resonant frequency, so there's no need to go in and tune the notch on the board.

Second order of business was to investigate the 18.34kHz peak in the transfer function. (Rana spent some time Monday night measuring this peak, and determined that it was at 18.34kHz) We decided that the best plan was to re-implement the Pomona Box notch filter that had previously existed to remove a higher frequency body mode, but tuned for the 18.34kHz mode. I am still not entirely sure what this mode is, but clearly it's a problem by about 20dB (on the TF, the next highest peak is 20dB below the 18.34kHz peak). Unfortunately, while the components should, by Matlab calculations, give me an 18.3kHz notch, I ended up with something like a 21.7kHz notch. This notch is approximately -30dB at 21.7kHz, and -20dB at 18.3kHz. I still need to take transfer functions and power spectra of the PMC servo with this new filter in place to (a) confirm that it did some good, and (b) to determine how important it is that the notch be right-on. More likely than not, I'll take the filter out and fiddle with the capacitors until I get the correct notch frequency.

Third on the list was to lock everything back up (FSS, PMC) after my tinkering, and see what kind of gain we get. Rob and I fiddled with the PMC gain, and it looks like the servo oscillates just before we get up to the max slider gain of 30dB. Looking at the power spectra in DTT, we do not see any significant peaks that suggest oscillation, so it is likely that there is some investigation to be done at frequencies above the 7kHz that we were able to look at with DTT (which isn't surprising, since all of this work has been at 14kHz and higher).

A final note is that we see a feature around 9kHz in the transfer function, and it is not at all clear where it comes from. At this time, it does not seem to be the dominant feature preventing us from increasing the gain, but at some point if we want the bandwidth of the PMC servo to be 10kHz, we'll have to figure this one out.

Still on the PMC todo list:

• Measure the new transfer function, see if 18.34kHz peak is reduced

• Tune Pomona Box notch filter to 18.3kHz instead of the current 21.7kHz

• Retake power spectra of different items on top of PMC, compare to see if there is any one configuration that it obviously better than the others.

• Find out why the PMC still oscillates when we try to take it up to the max slider gain, and fix it.

PS, is anyone else having trouble getting to the elog from laptops on other parts of the Caltech network (but not LIGO network)? My laptop won't go to the elog, but I can get to the rest of the internet using the Caltech wireless. My computer stopped seeing the elog on Tuesday or so. Joe, do you have any inspiration? Thanks.
522   Fri Jun 6 11:19:13 2008 CarynSummaryPEMFiltering MC_L and MC_F with PEM:ACC and microphone
Tried to filter MC_L and MC_F with acc/seis data and microphone data using wiener filter (levinson)

-Used get_mic_data.m and miso_filter_lev.m to make SISO filter for 2 minutes of IOO-MC_F data. Used PEM-AS_MIC signal as noise input data. Filters calculated at initial time were applied to later data in 1 hour intervals.
-microphone filter did not seem to filter MC_F very well in high frequency range using this filtering procedure.
-residual is larger than est (see MC_F pdf)
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-relation of max(rms(residual)) to N(order) is time sensitive (note-on graph, time interval is 1hour) (see MC_F pdf)
-Presumably, max(rms(residual)) should decrease as N increases and increase as time increases since the filter probably becomes worse with time. I think the reason this isn't always true in this case is that the max(rms(residual)) corresponds to a peak (possibly a 60Hz multiple) and the wiener filter isn't filtering out that peak very well.

-Used get_z_data.m and miso_filter_lev.m to make MISO filter for 2 minutes of IOO-MC_L used the following signals as noise input data
PEM-ACC_MC1_X
PEM-ACC_MC2_X
PEM-ACC_MC1_Y
PEM-ACC_MC2_Y
PEM-ACC_MC1_Z
PEM-ACC_MC2_Z
PEM-SEIS_MC1_Y
-Filter was applied to later data in 2hour intervals.
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-acc/seis filter seemed to filter MC_L OK for 128,256,512Hz srates. 64 Hz wasn't ok for certain N's after a period of time.
-residual is smaller than est for srates not 64Hz (see MC_L pdf)
-residual is larger than est for 64Hz at N=1448 for later times (see MC_L pdf)
-relation of max(rms(residual)) to N is not as time sensitive for higher sample rates (note-on graph, time interval is 2hours) (see MC_L pdf). Perhaps the levinson 64Hz sample rate filter doesn't do as well as time passes for these signals. When the filter didn't do well, the max(rms(residual)) seemed to increase with N.
-For 512Hz sample rate filter the max(rms(residual)) decreased with time. If the max(rms(residual)) were an indication of filter performance, it would mean that the 512Hz filter calculated at the initial time was performing better later as hours passed by! Perhaps max(rms(residual)) isn't always great at indicating filter performance.

Programming notes
-I had to modify values in do_all_time_lev.m to get the program to loop over the srates,N's,times I wanted
-do_all_time_lev.m is not as clean as do_all_lev.m
-for making the plots do_all_lev.m (which isn't really a procedure and is messy) has some examples of how to plot things from do_all_time_lev.m.
6049   Wed Nov 30 02:04:26 2011 rana, den, jenne, kiwamu, jzweizigUpdateCDSFiltering Noise issue tracked down ???

You can read through all of our past tests to see what didn't work in tracking things down. As Den mentions, there was actually a lot of evidence that there was some double->single precision action in the filter calculation causing the noise we saw.

However, it turns out that this is NOT the case.

This afternoon I was so confused that I enlisted JZ to help us out. He came over and I tried to replicate the error. When looking at the time series, we noticed that it wasn't random noise; the signals seem to be getting clipped as they crossed zero. Sort of like a stiction problem. JZ left to go replicate the error on an offline system.

This turned out to be the important clue. As we examine the code we find this inside of fm10Gen.c:

if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;

this is line is basically trapping the filter history at 1e-20, to prevent some kind of numerical underflow problem (?). Seems reasonable, except that some filters which have higher order low passing in them actually have an overall scale factor which can be small (even as small as 1e-23, as Den pointed out).

So the reason we saw such weird behavior is that the first filter in SUSPOS is an AC coupling filter. This takes the OSEM signal and remove the large mean value. Then the next filter multiplies it by 1e-23 before doing the filtering and you end up with this noise in the filter history.

I looked and this line is commented out in the new BiQuad code, but as far as I can tell this issue has been around in aLIGO, eLIGO, iLIGO, etc. for a long time and could have been causing many cases of excess noise whenever we ended up a tiny gain factor in an IIR filter. At the 40m, there are easily a hundred such cases.

For now, I suppose we can just change this number to 1e-40 or so. I don't know how to calculate what the right number should be. Not sure why this underflow is not an issue for the BiQuad, however.

6051   Wed Nov 30 11:04:26 2011 josephbUpdateCDSFiltering Noise issue tracked down ???

 Quote: For now, I suppose we can just change this number to 1e-40 or so. I don't know how to calculate what the right number should be. Not sure why this underflow is not an issue for the BiQuad, however.

According to the RCG SVN logs, the reason it was removed was a more general change done to the compiled code, not specific to just the biquad.  Basically, the ability to have an underflow number (subnormal) has been turned off completely by having any number that underflows set to zero. I'm not positive, but from a quick search looks that the smallest number before hitting is an underflow as a double is 2.2250738585072014e-308.

Alex's entry from the SVN log for 2663:

Added new fz_daz() function to turn on two bits in the FPU SSE control register.
Bits FZ (flush underflows to zero) and DOZ (denorms are zeros) are set to
avoid runaway code on float/double denorms (really small numbers).

SVN log 2664:

Removed +- 1e-20 limiting code, this is taken care of by setting FZ/DOZ bits
in the CPU SEE control register (see mathInline.h)

SVN log 2665:

Kill the underflows and roll down float denorms to zero,
see fz_doz() in mathInline.h.

6052   Wed Nov 30 11:36:12 2011 DenUpdateCDSFiltering Noise issue tracked down ???

 Quote: if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;

20 is indeed a random number. We can change it to 300. Alex said that during that iir filter calculations sometimes numbers are very small and if they are less then 1e-308 then a very slow code in the processor is executed and this will crash the online system. For single precision this number is 1e-38 and may be 10 years ago it was not decided for sure what to use - float or double. 20 will be "OK" for both but as we can see causes other problems.

Anyway, Alex removed this line from the code and added another code that sets the two proper bits in the MXCSR register and prohibits to the CPU to run the slow code. As far as I understand if the numbers are less then 1e-308 they become 0. Roughly, this is equivalent to

if((new_hist < 1e-308) && (new_hist > -1e-308)) new_hist = 0;

This is in 2.4 release. It is in the svn. I think we can install it and figure out if the problem is gone.

7074   Wed Aug 1 22:37:21 2012 JenneUpdateASSFilters installed in the ASS

As part of trying to figure out what is going on with the ASS, I wanted to figure out what filters are installed on which lockins.

Each "DoF"(1-6) has a zpk(0.1,0.0001,1)gain(1000), which is a lowpass with 60dB of gain at DC, and unity gain at high frequencies.

For the lockins, since there are so many, I made a spreadsheet to keep track of them (attached).

So, what's the point?  The point is, I think that all of the LOCKIN_I filter modules should be the same, with a single low pass filter.  The Q filter banks don't matter, since we don't use those signals, and the signals are grounded inside the model.  The phase of each lockin was / should be tuned such that all of the interesting signal goes to I, and nothing goes to Q.  The SIG filter modules seem okay, in that they're all the same, except for their band pass frequency.  I just need to check to see what frequency the ASS scripts are trying to actuate at, to make sure we're bandpassing the correct things.

11590   Thu Sep 10 09:37:34 2015 IgnacioSummaryIOOFilters left on MCL static module

The following MCL filters were left loaded in the T240-X and T240-Y FF filter modules (filters go in pairs, both on):

FM7: SISO filters for MCL elog:11541

FM8: MISO v1 elog:11547

FM9: MISO v1.1 Small improvement over MISO v1

FM10 MISO v2 elog:11563

FM5 MISO v3.1 elog:11584 (best one)

FM6 MISO 3.1.1 elog:11584 (second best one)

10239   Fri Jul 18 19:32:50 2014 AkhilSummaryElectronicsFilters used inside the Frequency Counter

Thanks Koji , for your  hint for the brain teasing puzzle. I was looking into Filters that are usually used in devices like counters, DSO and other scopes. I found that , to improve the quality of the measurement one of the best approach  is averaging. I looked deeper into averaging and found out this:

There are two general use-cases for averaging . The first, successive sample averaging, takes a single acquisition and averages between its samples. The second, successive capture averaging, combines the corresponding  samples of multiple captures to create a single capture. Successive sample averaging is also called boxcar filtering or moving average filtering. In an implementation of this type of averaging each output sample represents the average value of M consecutive input samples. This type of averaging removes noise (one of the reasons the noise level was not bad: http://nodus.ligo.caltech.edu:8080/40m/10151) by decreasing the device's bandwidth(could be one of the reasons why the FC operates in 4 different frequency ranges). It applies an LPF function with a 3dB point approximated by  0.433 * s / M, where M is the number of samples to be averaged, and s is the sample rate in samples per second.

Now I tried verifying the 3 dB points in the gain plots I generated :

For 1 s Sampling time : the 3 dB point for such a Boxcar filter should be at 0.433* 1/M. If we assume that it averages for 2 samples, M=2 which gives the 3dB point at 0.288 Hz but occurs somewhere between 0.3 and 0.4 Hz.  (http://nodus.ligo.caltech.edu:8080/40m/140619_120548/GainVsFreq.png)

For 0.1s Sampling time: the 3dB point should be at 2.17 Hz and in reality is 2.5 Hz(http://nodus.ligo.caltech.edu:8080/40m/140701_211904/gain.png).

Also, This type of filter will have very sharp nulls at frequencies corresponding to signals whose periods are integer sub-multiples of M/s. As seen my previous plots (http://nodus.ligo.caltech.edu:8080/40m/10118 , http://nodus.ligo.caltech.edu:8080/40m/10070) there are sharp nulls at frequencies

0.4 Hz for 1S sampling time and

at 1.5 Hz,3 Hz for 0.1 S sampling time as correctly predicted.

The moving average filter is  L-sample moving average FIR, with the frequency response as:   H(ω) = (1/L) (1 − e− jω L)/(1 − e− jω)..

There is an overall delay of (M - 1)/2 samples from such a length-M causal FIR filter.

The expected bode plots for such a filter with L= 5 is attached(attachment 2).

10246   Mon Jul 21 12:16:27 2014 AkhilSummaryElectronicsFilters used inside the Frequency Counter

The expected bode plots for such a filter with L= 4 is attached and compared with the measured.

RXA: When comparing two things, please put them onto the same plot so that they can be compared.

3437   Wed Aug 18 19:19:38 2010 JenneUpdateSUSFinal 2 TTs suspended!

[Jenne, Yoichi]

The final 2 Tip Tilts (#1 and #5) have been suspended.  We have designated #5 the spare.  It looks like there might be a teensy bit of dust on the AR surface of the optic in #5, right near the edge of the coating.  Not a critical issue if this one is the spare, although we should see if we can blow it off with the Nitrogen.  Both #1 and #5's optics were suspended using the thicker wire, 0.0036" diameter.  This leaves 4/5 TTs with this thick wire, and 1 of the 5 has the thin wire.

To do still: Balance both #1 and #5, and then measure the modes of each.  Then we'll be ready to install them into the chambers, and we'll reserve #5 for shake table TFs for some later date.

8113   Wed Feb 20 01:40:37 2013 ManasaUpdateAlignmentFinal IFO alignment- in progress

[Yuta, Sendhil, Jamie, Jenne, Rana]

1. After the MC centering, we tried to align the IFO using IPPOS and IPANG as reference. This did not recover the alignment perfectly. We were clipping at the BS aperture. Using TTs, we centered the beam at BS and PRM.
2. Using TTs, the beam was centered at ITMY and ETMY.
3. IPPOS and IPANG mirrors in-vacuum were aligned and were centered at the out-of-vacuum optics.
4. We checked the centering of the beam on optics in the BS and ITMY chamber. (Yuta will make an elog with the layout)
5. We retro-reflected ITMY at the BS and aligned ETMY such that we saw a couple of bounces in the arm cavity.
6. Using BS, the beam was steered to go through the center of ITMX and ETMX.
7. At this point we were able to see the MI fringes at the AS port.
8. We made fine alignments to the ITMX such that we saw MI reflected at the Farday.
9. We retro-reflected ITMX and aligned ETMX to see the beam bounce at the ITMX.
10. We aligned PRM such that PRC flashes. But we were not happy with the flashes (they were in higher order modes). We suspect that minor tuning of the input pointing might be necessary.
11. We closed for the day

8338   Mon Mar 25 16:51:43 2013 ChloeUpdate Final QPD Circuit Design

This is the final version of the QPD circuit I'm going to build. After playing around with the spatial arrangement, this should fit into the box that I was planning to use, although it will be a rather tight fit. The pitch, yaw, and summing circuit will be handled with a quad op amp. Planning to meet with Eric tomorrow to figure out the logistics of building things.

In the meantime, I'm reading about designing the ECDL for my summer project with Tara. He sent me several papers to read so we can talk on Wednesday.

11535   Fri Aug 28 00:59:55 2015 IgnacioUpdateIOOFinal SISO FF Wiener Filter for MCL

This is my final SISO Wiener filter for MCL that uses the T240-X seismo as its witness.

The main difference between this filter and the one on elog:11532 is the actual 1/f rolloff this filter pocesses. My last filter had a pair of complex zeroes at 2kHz, that gave the filter some unusual behavior at high frequencies, thanks Vectfit. This filter has 10 poles and 8 zeroes, something Vectfit doesn't allow for and needs to be done manually.

The nice thing about this filter is the fact that Eric and I turned this filter on during his 40 min PRFPMI lock last night, Spectra for this is coming soon.

This filter lives on the static Wiener path on the OAF machine, MCL to MC2, filter bank 7.

Anyways, the usual plots are shown below.

Filter:

T240-X (SISO)

Training data + Predicted FIR and IIR subtraction:

Online subtraction results:(High freq. stuff shown for noise injection evaluation of the filter)

MCL

YARM

Subtraction performace:

14764   Tue Jul 16 15:17:57 2019 KojiHowToCDSFinal bit bug of the BIO CDS module

Yutaro talked about the BIO bug in KAGRA elog. http://klog.icrr.u-tokyo.ac.jp/osl/?r=9536

I think I made the similar change for the 40m model somewhere (don't remember), but be aware of the presense of this bug.

14890   Tue Sep 17 14:43:59 2019 gautamHowToCDSFinal bit bug of the BIO CDS module

Came across this while looking up the BIO situation at 1Y2. For reference, the fix Koji mentions can be seen in the attached screenshot (one example, the other BIO cards also have a similar fix). The 16th bit of the BIO is grounded, and some bit-shifting magic is used to implement the desired output.

 Quote: Yutaro talked about the BIO bug in KAGRA elog. http://klog.icrr.u-tokyo.ac.jp/osl/?r=9536 I think I made the similar change for the 40m model somewhere (don't remember), but be aware of the presense of this bug.
14941   Fri Oct 4 22:22:03 2019 gautamUpdateCDSFinal incarnation of latch.py

[KA, GV]

This elog is meant to be a summary of some of the many subtleties on the CM board. The latest schematic of the version used at the 40m can be found at D1500308 .

Latch logic:

• There are several Binary Outputs and one Binary Input to the CM board.
• The outputs control ENABLE/DISABLE switches and gains of amplifier stages, while the input reports whenever the limiter has been reached.
• The variable gain feature is implemented by enabling/bypassing several cascaded fixed gain stages. So in order to change the gain of a single composite amplifier stage, multiple individual amplifier stages have to be switched.
• This is implemented by the user interacting with the hardware via a "control word", consisting of a number of bits depending on the number of cascaded stages that have to be switched.
• This control word is sent to the device via modbus EPICS, which is an asynchronous communication protocol. Hence, it may be that the individual bits composing the control word get switched asynchronously. This would be disastrous, as there can be transient glitches in the gain of the stage being controlled.
• To protect against such problems, there is a latch IC in the hardware between the Binary Inputs to the board (= Binary Outputs from Acromags), and the actual switches (= MAX333) that enable/bypass the cascaded gain stages. The latch IC used is a SN74ALS573. This device acts as a bus, which transmits/blocks changes for multiple bits (= our control word) from propagating, depending on the state of a single bit (= the LATCH ENABLE bit). Thus, by controlling a single bit, we can guarantee that multiple bits get switched synchronously
• In order to use this latch capability, we need some software logic that sets/disables the LATCH ENABLE bit. For our system, this logic is implemented in the form of a continuously running python 🐍 script, located at /cvs/cds/caltech/target/c1iscaux/latch.py. It is implemented as a systemctl service on the c1iscaux Supermicro. The logic implemented in this script is shown in Attachment #1. While the channels referred to in that attachment are for REFL1_GAIN, the same logic is implemented for REFL2_GAIN, AO_GAIN, and the SuperBoosts.
• Some FAQ:
1. Q: Why do we need the soft channels C1:LSC-REFL1_SET_LSB and C1:LSC-REFL1_SET_MSB?
A: These soft channels are what is physically linked to the Acromag Binary Outputs. In order for our latch logic to be effective, we need to detect when the user asks for a change, and then disable the LATCH ENABLE bit (which is on by default, see FAQ #3) before changing the physical acromag channels. The soft channels form the protective layer between the user and the hardware, allowing latch.py to function.
2. Q: Why is there an "_MSB" and "_LSB" soft channel?
A: This has to do with the mbboDirect EPICS channel type, which is used to control the multiple bits in our control word using a single input (= an MEDM gain slider). The mbboDirect data-type requires the bits it controls to have consecutive hardware addresses. However, the Acromag hardware addressing scheme is not always compatible with this requirement (see pg 33 of the manual for why this is the case). Hence, we have to artifically break up the control word into two separate control words compatible with the Acromag addressing scheme. This functionality is implemented in latch.py.
3. Q: Why is the default state of LATCH ENABLE set to ON?
A: This has to do with the fact that all Binary Inputs, not just the multi-bit ones, to the CM board are propagated to the control hardware via a latch IC. For the single-bit channels, there is no requirement that the switching be synchronous. Hence, rather than setting up ~10 more single-bit soft channels and detecting changes before propagating them, we decided to leave the LATCH ENABLE ON by default, and only disable it when changing the multi-bit gain channels. This is the same way the logic was implemented in the VME state code, and we think that there are no logic reasons why it would fail. But if someone comes up with something, we can change the logic.

Acromag BIO testing:

During my bench testing of the Acromag chassis, I had not yet figured out mbboDirect and the latch logic, so I did not fully verify the channel mapping (= wiring inside the Acromag box), and whether the sitching behavior was consistent with what we expect. Koji and I verified (using the LED tester breakout board) that all the channels have the expected behavior 👏. Note that this is only a certification at the front-panel DB37 connectors of the Acromag chassis  testing of the integrated electronics chain including the CM board is in progress...

14947   Tue Oct 8 03:19:14 2019 KojiUpdateCDSFinal incarnation of latch.py

Now with the CM board tested with the signal injected, it turned out that the latch logic was flipped. As the default state locked the digital levels, the buttons other than the mbbo channels were inactive.

By giving 0 to C1:LSC-CM_LATCH_ENABLE, the modification of the digital state is enabled. And with the value of 1, the digital bits on the board is locked.

In order to reflect this, latch.py was modified and now the controls are all activated.

941   Thu Sep 11 11:29:14 2008 josephbConfigurationComputersFinal netgear switch in place in 1Y2
I've placed the final (of 4) Netgear prosafe 24 port switch at the very top of 1Y2. At that location, there are no holes left to screw into, so it has 4 rubber feet and is sitting on the top most signal generator. It has been plugged in and connected to the control room hub with a labeled cat6 ethernet cable.

Its IP address has been set to 131.215.113.253, and has the usual controls password if using the "Smart Wizard Discovery Tool" which comes on the Netgear CD. The CD can be found in the Equipment manuals filing cabinet under Netgear. This program unfortunately only runs on a window PC.

To Do: Fix the C1:ASC ethernet connection which is currently coming straight out the front door and connected to the 1X4 switch (again through the front door).
8961   Fri Aug 2 21:59:36 2013 CharlesUpdateISSFinalized ISS Schematic (hopefully)

Attached is the finalized schematic. The general circuit topology should remain the same from this point forward, although individual component values are subject to change. I will also be adding some more annotations to ensure everything on the board is clear.

In general, I have finally included all of the correct components (i.e. front panel switches are now actually switches and front panel LEDs are now included). I also added an external 'Boost' switch, which can be used to enable or disable the boosts. The motivation for including this switch is that one might want to test functionality of the ISS without using the 'fancy' RMS detection and triggering circuitry. Additionally, one can disable the boosts when all the circuitry is stuffed in order to troubleshoot, so it essentially grants the board some flexibility in its operation.

I am now working on the PCB layout and I should hopefully have that done next week.

16988   Mon Jul 11 19:29:23 2022 PacoSummaryGeneralFinalizing recovery -- timing issues, cds, MC1

[Yuta, Koji, Paco]

Restarting CDS

We were having some trouble restarting all the models on the FEs. The error was the famous 0x4000 DC error, which has to do with time de-synchronization between fb1 and a given FE. We tried a combination of things haphazardly, such as reloading the gpstime process using

controls@fb1:~ 0$sudo systemctl stop daqd_* controls@fb1 :~ 0$ sudo modprobe -r gpstime
controls@fb1:~ 0$sudo modprobe gpstime controls@fb1:~ 0$ sudo systemctl start daqd_*
controls@fb1:~ 0$sudo systemctl restart open-mx.service without much success, even when doing this again after hard rebooting FE + IO chassis combinations around the lab. Koji prompted us to check the local times as reported by the gpstime module, and comparing it to network reported times we saw the expected offset of ~ 3.5 s. On a given FE ("c1***") and fb1 separately, we ran: controls@c1***:~ 0$ timedatectl
Local time: Mon 2022-07-11 16:22:39 PDT
Universal time: Tue 2022-07-11 23:22:39 UTC
Time zone: America/Los_Angeles (PDT, -0700)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2022-03-13 01:59:59 PST
Sun 2022-03-13 03:00:00 PDT
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2022-11-06 01:59:59 PDT
Sun 2022-11-06 01:00:00 PST
controls@fb1:~ 0$ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 192.168.123.255 .BCST. 16 u - 64 0 0.000 0.000 0.000 which meant a couple of things: 1. fb1 was serving its time (broadcast to local (martian) network) 2. fb1 was not getting its time from the internet 3. c1*** was not synchronized even though fb1 was serving the time By looking at previous elogs with similar issues, we tried two things; 1. First, from the FEs, run sudo systemctl restart systemd-timesyncd to get the FE in sync; this didn't immediately solve anything. 2. Then, from fb1, we tried pinging google.com and failed! The fb1 was not connected to the internet!!! We tried rebooting fb1 to see if it connected, but eventually what solved this was restarting the bind9 service on chiara! Now we could ping google, and saw this output controls@fb1:~ 0$ ntpq -p
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+tor.viarouge.ne 85.199.214.102   2 u  244 1024  377  144.478    0.761   0.566
*ntp.exact-time. .GPS.            1 u   93 1024  377  174.450   -1.741   0.613
time.nullrouten .STEP.          16 u    - 1024    0    0.000    0.000   0.000
+ntp.as43588.net 129.6.15.28      2 u  39m 1024  314  189.152    4.244   0.733
192.168.123.255 .BCST.          16 u    -   64    0    0.000    0.000   0.000

meaning fb1 was getting its time served. Going back to the FEs, we still couldn't see the ntp synchronized flag up, but it just took time after a few minutes we saw the FEs in sync! This also meant that we could finally restart all FE models, which we successfully did following the script described in the wiki. Then we had to reload the modbusIOC service in all the slow machines (sometimes this required us to call sudo systemctl daemon-reload) and performed burt restore to a last Friday's snap file collection.

IMC realign and MC1 glitch?

With Koji's help PMC locked, and then Yuta and Paco manually increased the input power to the IFO by rotating the waveplate picomotor to 37.0 deg. After this, we noticed that the MC REFL spot was not hitting the camera, so maybe MC1 was misaligned. Paco checked the AP table and saw the spot horizontally misaligned on the camera, which gave us the initial YAW correction on MC1. After some IMC recovery, we saw only MC1 got spontaneously kicked along both PIT and YAW, making our alignment futile. Though not hard to recover, we wondered why this happened.

We went into the 1X4 rack and pushed MC1 suspension cables in to disregard loose connections, but as we came back into the control room we again saw it being kicked randomly! We even turned damping off for a little while and this random kicking didn't stop. There was no significant seismic motion at the time so it is still unclear of what is happening.

2983   Tue May 25 16:40:27 2010 josephb, alexUpdateCDSFinally tracked down why new models wouldn't talk to each other

The problem with the new models using the new shared memory/dolphin/RFM defined as names in a single .ipc file.

The first is the no_oversampling flag should not be used.  Since we have a single IO processor handling ADCs and DACs at 64k, while the models run at 16k, there is some oversampling occuring.  This was causing problems syncing between the models and the IOP.

It also didn't help I had a typo in two channels which I happened to use as a test case to confirm they were talking.  However, that has been fixed.

17006   Fri Jul 15 16:20:16 2022 Cici HannaUpdateGeneralFinding UGF

I have temporarily abandoned vectfit and aaa since I've been pretty unsuccessful with them and I don't need poles/zeroes to find the unity gain frequency. Instead I'm just fitting the transfer function linearly (on a log-log scale). I've found the UGF at about 5.5 kHz right now, using old data - next step is to get the Red Pitaya working so I can take data with that. Also need to move this code from matlab to python. Uncertainty's propagated using the 95% confidence bounds given by the fit, using curvefit - so just from the standard error, and all points are weighted equally. Ideally would like to propagate uncertainty accounting for the coherence data too, but haven't figured out how to do that correctly yet.

[UPDATE 7/22/2022: added raw data files]

16993   Tue Jul 12 18:35:31 2022 Cici HannaSummaryGeneralFinding Zeros/Poles With Vectfit

Am still working on using vectfit to find my zeros/poles of a transfer function - now have a more specific project in mind, which is to have a Red Pitaya use the zero/pole data of the transfer function to find the UGF, so we can check what the UGF is at any given time and plot it as a function of time to see if it drifts (hopefully it doesn't). Wrestled with vectfit more on matlab, found out I was converting from dB's incorrectly (should be 10^(dB/20)....) Intend to read a bit of a book by Bendat and Piersol to learn a bit more about how I should be weighting my vectfit. May also check out an algorithm called AAA for fitting instead.

8322   Thu Mar 21 09:53:46 2013 AnnalisaUpdateLockingFinding the beat note

Yesterday I tried to find the beat note between the main PSL and the auxiliary NPRO, but I didn't :(

Today I will do a better alignment of the two beams in the PD and try again.

8323   Thu Mar 21 10:19:28 2013 KojiUpdateLockingFinding the beat note

What PD are you using? How much power the beams on the recombining BS are? What kind of BS is it?
How are you looking for the beat note? (on the scope? or spectrum analyzer?)
What was the scanned temp range?

Three points to be checked:

- Polarization

- Alignment

- Temperature

8327   Thu Mar 21 13:11:42 2013 AnnalisaUpdateLockingFinding the beat note

 Quote: Give us more info on the elog: What PD are you using? How much power the beams on the recombining BS are? What kind of BS is it? How are you looking for the beat note? (on the scope? or spectrum analyzer?) What was the scanned temp range? Three points to be checked: - Polarization - Alignment - Temperature

Experimental Setup

I'm using a 1611 New Focus PD (1 GHZ, with maximum input power 1mW), and the total power hitting on the PD is of about 0.650 mW.

The current of the NPRO laser is set to 1.38 A, so that the input power is 19 mW. The beam is initially damped by a 10% reflection BS and then it hits a 33% reflection BS (where it recombines with the PSL pick-off beam) with 2 mW power.

After this second BS the power is reduced to 0.592 mW.

The PSL pick-off hits on the 33% reflection BS with 65.5 uW power, and it exit with a 47 uW power.

I connected a power supply to apply a Voltage to the slow frequency BNC, in way to tune the laser frequency.

I'm using the AGILENT 4395A Spectrum analyzer to make the measurement. I tried to use the HEWELETT PACKARD 8591E spectrum analyzer, but the monitor didn't turn on.

The temperature spanned until now in only of about 10 deg C, because I realized that I needed a better alignment, so I added a lens in front of the PD and I did a better alignment.

Moreover, the current of the laser is too low, so I need to increase it and add more beam splitters in the beam path to dump the beam, in way to don't reach the PD threshold.

I knew that both the beams are s-polarized, but maybe I can check it again.

541   Wed Jun 18 18:26:19 2008 YoichiUpdatePSLFinding the optimal operation temperature for the NPRO by the slow act scan
Being suspicious of the temperature stabilization of the NPRO crystal, I ran the slow scan script written by Rana to find the suitable operation temperature.
The procedure is the same as the one explained in the entry below:
The attached plots show the results. By looking at C1:PSL-126MOPA_126MON, I set the slow slider voltage to 0.
This time, it looks like the temperature control of the NPRO crystal is working fine.
Obviously, PMC picks up many higher order modes. I will try to mode match/align the PMC later.
7953   Tue Jan 29 14:20:02 2013 KojiUpdateGeneralFiner rotation stage for optics characterization

A rotation stage has been ordered.

 Newport Rotation Stage, 360° Coarse, 5° Fine Rotation, Micrometer Newport 481-A Newport Solid Insert for RSP-1T Rotation Stage Newport RSA-1TI Newport Universal Mounting Plate, 2.56 in. x 2.56 in. x 0.5 in., 1/4-20 Thread Newport UP-1A

Specification: Newport 481-A

• Sensitivity: 15 arcsec
• Vernier: 5 arcmin
• Fine travel range: 5 deg
• With Micrometer
15618   Thu Oct 8 08:37:15 2020 gautamUpdateComputer Scripts / ProgramsFinesse GUI

This looks cool, we should have something similar, can be really useful.

15621   Thu Oct 8 18:40:42 2020 KojiUpdateComputer Scripts / ProgramsFinesse GUI

Is it better than Luxor? https://labcit.ligo.caltech.edu/~jharms/luxor.html

14057   Thu Jul 12 14:06:39 2018 keerthanaUpdateelogFinesse and Analytical solution - Comparison

I tried to compare the cavity scan data we get from the Finesse simulation and that we expect from the Analytical solution. The diagram of the cavity I defined in Finesse is given below along with the values of different quantities I used. For the analytical solution I have used two different equations and they are listed below.

Analytical 1 - Blue Graph

$\phi = \frac {2.L.\Omega_1}{c}$

$t_{cav} = \frac{t_e. t_f \exp^{-i\frac{\phi}{2}}}{1- r_f. r_e \exp^{-i\phi} }$

$T_{cav} = \left|{t_{cav}} \right|^2$

Analytical 2 - Red Graph

$F = \frac {4. r_f.r_e}{(1-r_f.r_e )^2}$

$\phi = \frac {2.L.\Omega_1}{c}$

$T_{cav} = \left|{t_{cav}} \right|^2 = \frac {(t_e.t_f)^2}{(1 - r_f . r_e)^2} \frac{1}{1+F(\sin\frac {\phi}{2})^2}$

The graph obtained from both these solutions completely matches with each other.

Finesse Solution

The cavity which I defined in Finesse is shown below. The solution from Finesse and the Analytical solution also matches with each other. Another plot is made by taking the difference between Finesse solution and Analytical solution. The difference seems to be of the order of $\approx 10^{-19}$.

The Difference plot is also attached below.

13915   Mon Jun 4 19:41:01 2018 keerthanaUpdate Finesse code for cavity scan

The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.

13956   Wed Jun 13 18:08:36 2018 keerthanaUpdate Finesse code for cavity scan

The unit mentioned in the x-axis was wrong. So I have remade the graphs. The point where frequency equals to zero is actually the frequency corresponding to the laser, which is in the range of 1014 Hz and it caliberated as zero.

 Quote: The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.
12120   Wed May 18 01:10:22 2016 gautamUpdateCOCFinesse modelling

I've been working on putting together a Finesse model for the current 40m configuration. The idea was to see if I could reproduce a model that is in agreement with what we have been seeing during the recent DRFPMI locks. With Antonio and EricQs help, I've been making slow progress in my forays into Finesse and pyKat. Here is a summary of what I have so far.

• Arm lengths were taken from some recent measurements done by yutaro and me
• Recycling cavity lengths were taken from Gabriele's elog 9590 - it is likely that the lengths I used have errors ~1cm - more on this later. Furthermore, I've tried to incorporate the flipped RC folding mirrors - the point being to see if I can recover, for example, a power recycling gain of ~7 which is what was observed for the recent DRFPMI locks.
• I used Yutaro's most recent arm loss numbers, and distributed it equally between ITM and ETM for modeling purposes.
• For all other optics, I assumed a generic loss number of 25ppm for each surface

Having put together the .kat file (code attached, but this is probably useless, the new model with RC folding mirrors the right way will be what is relevant), I was able to recover a power recycling gain of ~7.5. The arm transmission at full lock also matches the expected value (125*80uW ~ 10mW) based on a recent measurement I did while putting the X endtable together. I also tuned the arm losses to see (qualitatively) that the power recycling gain tracked this curve by Yutaro. EricQ suggested I do a few more checks:

1. Set PRM reflectivity to 0, scan ETMs and look at the transmission - attachment #1 suggests the linewidth is as we expect
2. Set ETM reflectivity to 0, scan PRM - attachment #2 suggests a Finesse of ~60  for the PRC which sounds about right
3. Set ETM reflectivity to 0, scan SRM and verify that only the 55 MHz sidebands resonate - Attachment #3

Conclusion: It doesn't look like I've done anything crazy. So unless anyone thinks there are any further checks I should do on this "toy" model, I will start putting together the "correct" model - using RC folding mirrors that are oriented the right way, and using the "ideal" RC cavity lengths as detailed on this wiki page. The plan of action then is

• Evaluating the mode-matching integrals between the PRC and the arm cavities as a function of the radius of curvature of PR2 and PR3
• Same as above for the SRC
• PRC gain as a function of RoC of folding mirrors
• Mode overlap between the modes from the two arm cavities as a function of the RoC of the two ETMs (actually I guess we can fix RoC of ETMy and just vary RoC of ETMx).

Sidenote to self: It would be nice to consolidate the most recent cavity length measurements in one place sometime...

12130   Tue May 24 22:49:02 2016 gautamUpdateCOCFinesse modelling - mode overlap scans

Summary:

Having played around with a toy finesse model, I went about setting up a model in which the RC folding mirrors are not flipped. I then repeated the low-level tests detailed in the earlier elog, after which I ran a few spatial mode overlap analyses, the results of which are presented here. It remains to do a stability analysis.

Overview of model parameters (more details to follow):

• PRC length = 6.7727m (chosen using $\dpi{80} l_{PRC} = (N+\frac{1}{2})\frac{c}{2f_1}$, N=0 - I adjusted the position of the PRM to realize this length in the model, while leaving all the other vertex optics in the same positions as in elog 9590
• SRC length = 5.4182 (chosen using $\dpi{80} l_{SRC} = M\frac{c}{2f_2}$ but not $\dpi{80} l_{SRC} = N\frac{c}{2f_1}$, M and N being integers, for M=2 - as above, I adjusted the position of the SRM to realize this in the model, while leaving all other vertex optics in the same positions as in elog 9590. It remains to be verified if it is physically possible to realize these dimensions in vacuum without any beam clipping etc but I think it should be possible seeing as the PRM and SRM had to be moved by less than 2cm from their current positions..
• For the losses, I used the most recent numbers we have where applicable, and put in generic 25ppm loss for all the folding mirrors/BS/AR surfaces of arm cavity mirrors/PRM/SRM. Arm round trip loss was equally distributed between ITMs and ETMs
• Arm lengths used: L_X = 37.79m, L_Y = 37.81m
• To set the "tunings" of the various mirrors, I played around with a few configurations to see where the various fields resonated - it turns out that for PRM, ITMX, ITMY, ETMX and ETMY, the "phase" in the .kat file can be set as 0. while that for the SRM can be set as 90. In the full L1/H1 interferometer .kat files, these are tuned even further to the (tenth?!) decimal place, but I think these values suffice for out purposes.

Results (general note: positive RoC in these plots mean a concave surface as seen by the beam):

• Attachments #1, #2 and #3 reproduce the low-level tests performed earlier for this updated model - i.e. I look at the arm transmission with no PRM/SRM, circulating PRC power with no ETMs, and circulating SRC power with no ETMs. Everything looks consistent here... In Attachment #2, there is no legend, but the (almost overlapping) red and green lines are meant to denote the +f1 and +f2 sidebands.
• Attachments #4 and #5 are a summary of the mode-overlap scans for the PRC and SRC. What I did was to vary the radius of curvature of the RC mirrors (finesse only allows you to vary Rcx and Rcy, so I varied both simultaneously) and calculate the mode overlap between the appropriate pairs of cavities (e.g. PRX and XARM) in the tangential and saggital planes. The take-away here is that there is ~5% mode-mismatch going from an RoC of 1000m to 300m. I've also indicated the sag corresponding to a given RoC - these are pretty tiny, I wonder if it is possible to realize a sag of 1um? I suppose it is given that I've regularly seen specs of surface roughness of lambda/10?
• Attachment #6 shows the PRC gain (calculated as T_PRC * (transmitted arm power with PRM / transmitted arm power without PRM) as a function of the RoC of PR2 and PR3. As a sanity check, I repeated this calculation with lossless HR surfaces (but with nominal 25ppm losses for AR surfaces of ITMs, and BS etc), shown in Attachment #7. I think these make sense too...
• Attachment #8 - in order to investigate possible mode mismatch between the arm modes due to different radii of curvature of the ETMs, I kept the ETMY RoC fixed at 57.6m and varied the ETMY RoC between 50m and 70m (here, I've plotted the mode matching efficiency as a function of the RoC of the ETM in the X and Y directions separately - the mode overlap is computed as $\dpi{80} \frac{1}{\sqrt{2}}(x^2 + y^2)$ where x and y denote the overlap in the tangential and saggital planes respectively. It would seem that we only lose at most a couple of percent even if the RoCs are mismatched by up to 10m...
• Attachment #9 - .kat file and the various pykat scripts used to generate these plots...

Next step is to carry out a stability analysis...

12131   Tue May 24 23:17:37 2016 ericqUpdateCOCFinesse modelling - mode overlap scans

I think you should use the current actual PRC & SRC cavity lengths as measured, as it would be simplest to simply replace the folding mirror optics without changing the macroscopic lengths / optic positions. (EDIT: Gautam rightly points out that we have to move things around regardless, since our current lengths include propagation through the folding mirror subtrates)

Moreover, the recycling cavity lengths you posted are not the right "ideal" lengths to use, as they do not account for the complex reflectivities of the sidebands off of the arm cavities (I have made this mistake myself). See this 40m wiki page for details.

In short, given our current modulation frequency, the ideal lengths to use would be:

• Ideal arm length of 37.795 m
• Ideal PRC length of 6.753 m
• Ideal SRC length of 5.399 m

These are the lengths that the recycling cavity optics were positioned for (though we did not achieve them perfectly). If you do a finer PRC/SRC length scan around the DRFPMI resonance of your model, you would presumably see some undesired sideband splitting.

2903   Mon May 10 17:47:16 2010 josephbSummaryCDSFinished

So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator),  parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels).

The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py

I still need to add all the nice command line interface stuff, but the basic core works.   And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently.

Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight.

2908   Mon May 10 20:33:29 2010 KojiSummaryCDSFinished

This IPC stuff looks really a nice improvement of CDS.

Please just maintain the wiki updated so that we can keep the latest procedures and scripts to build the models.

 Quote: So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator),  parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels).  The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py I still need to add all the nice command line interface stuff, but the basic core works.   And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently. Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight.

16499   Fri Dec 10 15:59:23 2021 PacoUpdateBHDFinished Coil driver (even serial number) units tests

[Paco, Anchal]

We have completed modifications and testing of the HAM Coil driver D1100687 units with serial numbers listed below. The DCC tree reflects these changes and tests (Run/Acq modes transfer functions).

 SERIAL # TEST result S2100608 PASS S2100610 PASS S2100612 PASS S2100614 PASS S2100616 PASS S2100618 PASS S2100620 PASS S2100622 PASS S2100624 PASS S2100626 PASS S2100628 PASS S2100630 PASS S2100632 PASS S2101648** FAIL (Ch1, Ch3 run mode) S2101650** FAIL (Ch3 run mode) S2101652** PASS S2101654** PASS

** A fix had to be done on the DC power supply for these. The units' regulated power boards were not connected to the raw DC power, so the cabling had to be modified accordingly (see Attachment #1)

16514   Thu Dec 16 15:32:59 2021 AnchalUpdateBHDFinished Coil driver (odd serial number) units tests

We have completed modifications and testing of the HAM Coil driver D1100687 units with serial numbers listed below. The DCC tree reflects these changes and tests (Run/Acq modes transfer functions).

 SERIAL # TEST result S2100609 PASS S2100611 PASS S2100613 PASS S2100615 PASS S2100617 PASS S2100619 FAIL (CH2 phase) S2100621 PASS S2100623 PASS S2100625 PASS S2100627 PASS S2100629 PASS S2100631 PASS S2100633 Waiting for more components S2101649** PASS S2101651** PASS S2101653** PASS S2101655** PASS

** A fix had to be done on the DC power supply for these. The units' regulated power boards were not connected to the raw DC power, so the cabling had to be modified accordingly.

Further, Paco fixed the two even serial number units (S2101648, S211650) that failed the test. The issues were minor soldering mistakes that were easily resolved.

16517   Thu Dec 16 17:57:17 2021 AnchalUpdateBHDFinished Coil driver (odd serial number) units tests

S2100619 was fixed by Koji and it passed the test after that.

Quote:
 SERIAL # S2100619 FAIL (CH2 phase)

12329   Mon Jul 25 10:54:55 2016 PrafulUpdateComputer Scripts / ProgramsFinished MEDM Tab on Summary Pages

The MEDM screen capture tab is now working and up on the summary pages: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160725/medm/

Please let me know if you have any suggestions or notice any issues.

12330   Mon Jul 25 12:22:18 2016 ranaUpdateComputer Scripts / ProgramsFinished MEDM Tab on Summary Pages

Looks pretty great. However, there's two problems:

1) Some of the MEDM screens don't show the time. You can fix this by editing the screens and copy/paste from screens which have working screens.

2) The snapshot script seems to not grab the full MEDM screen sometimes.

These are not a very big deal, so you can get the microphones working first and we can take care of this afterwards.

12439   Wed Aug 24 23:47:30 2016 PrafulUpdateElectronicsFinished Prototype Box

Gautam helped me drill holes in a metal box and I set up my circuit inside. Everything seems to be working so far. Tomorrow I'll be suspending the box near the PSL and setting up a data channel. Attached are some pictures of the box- sorry some of the angles turned out weird.

3116   Thu Jun 24 16:59:24 2010 josephbUpdateVACFinished restoring the access connector and door

[Jenne,  Kiwamu, Steve, Sharmila, Katherine, Joe]

We finished bolting the door on the new ITMX (old ITMY) and putting the access connector section back into place.  We finished with torquing all the bolts to 40 foot-pounds.

2597   Fri Feb 12 13:56:16 2010 josephbUpdateComputersFinishing touches on IP switch over

The GPIB interfaces have been updated to the new 192.168.113.xxx addresses, with Alberto's help.

Spare ethernet cables have been moved into a cabinet halfway down the x-arm.

The illuminators have a white V error on the alarm handler, but I'm not sure why.  I can turn them on and off using the video screen controls (except for the x arm, which has no computer control, just walk out and turn it on).

There's a laptop or two I haven't tracked down yet, but that should be it on IPs.

At some point, a find and replace on 131.215.xxx.yyy addresses to 192.168.xxx.yyy should be done on the wiki.  I also need to generate an up to date ethernet IP spreadsheet and post it to the wiki.

4056   Wed Dec 15 12:46:18 2010 KojiSummaryIOOFinishing up the vac work

What else?

v: Edit on Dec 15 10PM v: Edit on Dec 16 10PM 

JD:  We should check OSEMs for all optics *after* table leveling.  Some of them (esp. BS and ITMX) are currently close to their limits right now.

KA: Check green alignment.

Take photos of the tables.

Fix the leveling weights

 Location    Optics            Action -------------------------------------------------------------- @ITMX -     v POX             alignment             v POP1/POP2       alignment             v Table Leveling

@ITMY -     POY               mirror replacement (45deg->0deg) / alignment             v SR2-TT          alignment             v SRM Tower       alignment / EQ-stop release             v SRM             alignment             v SRM OSEM             vvSRM OPLEV (X2)  install (VIS)/ alignment             v ITMY OPLEV (X2)   install (VIS)/ alignment             v OM1/OM2         install (DLC 45deg)/ alignment                    v Table Leveling

@BSC -      v OM3             install (DLC 45deg/ alignment)             v OM4(PZT)          neutralize, adjustment             IPPOS steering    alignment             v BS OPLEV        alignment             v PRM OPLEV(x2)     alignment             Beam dumps             Table Leveling

@IMC -      v REFL              mirror replacement　(45deg->0deg)

@ETMX -     Al foil removal             Table Leveling

@ETMY -     ETMY damping             OSEM             OPLEV             Al foil removal             Table Leveling

@OMC -      v OM5(PZT)        neutralize, adjustment

@ITM/ETM -  Mirror Wiping 

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.

ELOG V3.1.3-