40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 224 of 339 Not logged in
ID Date Author Type Category Subject
14632   Thu May 23 08:51:30 2019 MilindUpdateCamerasSetting up beam spot simulation

I have done the following thus far since elog #14626:

Simulation:

1. Cleaned up Pooja's code for simulating the beam spot. Added extensive comments and made the code modular. Simulated the Gaussian beam spot to exhibit
1. Horizontal motion
2. Vertical motion
3. motion along both x and y directions:
2. The motion exhibited in any direction in the above videos is the combination of four sinusoids at the frequencies: 0.2, 0.4, 0.1, 0.3 Hz with amplitudes that can be found as defaults in the script ((0.1, 0.04, 0.05, 0.08)*64 for these simulations.). The variation looks as shown in Attachment 1. For the sake of convenience I have created the above video files with only a hundred frames (fps = 10, total time ~ 10s) and this took around 2.4s to write. Longer files need much longer. As I wish to simply perform image processing on these frames immediately, I don't see the need to obtain long video files right away.
3. I have yet to add noise at the image level and randomness to the motion itself.  I intend to do that right away. Currently video 3 will show you that even though the time variation of the coordinates of the center of the beam is sinusoidal, the motion of the beam spot itself is along a line as both x and y motions have the same phase. I intend to add the feature of phase between the motion of x and y coordinates of the center of the beam, but it doesn't seem all too important to me right now. The white margins in the videos generated are annoying and make tracking the beam spot itself slightly difficult as they introduce offset (see below). I shall fix them later if simple cropping doesn't do the trick.
4. I have yet to push the code to git. I will do that once I've incorporated the changes in (3).

Circle detection:

1. If the beam spot intensity variation is indeed Gaussian (as it definitely is in the simulation), then the contours are circular. Consequently, centroid detection of the beam spot reduces to detecting these contours and then finding their centroid (center). I tried this for a simulated video I found in elog post 14005. It was a quick implementation of the following sequence of operations: threshold (arbritrarily set to 127), contour detection (video dependent and needs to be done manually), centroid determination from the required contour.  Its evident that the beam spot is being tracked (green circle in the video). Check #Attachment 2 for the results. However, no other quantitative claims can be made in the absence of other data.
2. Following this, Gautam pointed me to a capture in elog post 13908. Again, the steps mentioned in (1) were followed and the results are presented below in Attachment #3. However, this time the contour is no longer circular but distorted. I didn't pursue this further. This test was just done to check that this approach does extend (even if not seamlessly) to real data. I'm really looking forward to trying this with this real data.
3. So far, the problem has been that there is no source data to compare the tracked centroid with. That ought to be resolved with the use of simulated data that I've generated above. As mentioned before, some matplotlib features such as saving with margins introduce offsets in the tracked beam position. However, I expect to still be able to see the same sinusoidal motion. As a quick test, I'll obtain the fft of the centroid position time series data and check if the expected frequencies are present.

I will wrap up the simulation code today and proceed to going through Gabriele's repo. I will also test if the contour detection method works with the simulated data. During our meeting, it was pointed out that when working with real data, care has to be taken to synchronize the data with the video obtained. However, I wish to put off working on that till later in the pipeline as I think it doesn't affect the algorithm being used. I hope that's alright (?).

Attachment 1: variation.pdf
Attachment 2: contours_simulated.mp4
Attachment 3: contours_real.mp4
16449   Thu Nov 4 18:29:51 2021 TegaUpdateSUSSetting up suspension test model

[Ian,Tega]

Today we continued working on setting up the 6 degrees of freedom model for testing the suspension which we copied over from  "/cvs/cds/rtcds/userapps/release/sus/c1/models/c1sup.mdl" to c1sp2.mdl in the same folder. We then changed the host from c1lsc to c1sus2, changed cpu # from 7 to 3 bcos c1sus2 has 6 cores. Then ran the following commands to build and install the model on c1sus2:

$ssh c1sus2$ rtcds make c1sp2

rtcds install c1sp2 where we encountered the following installation error: ERROR: This node 62 is already installed as: hostname=c1lsc system=c1sup The new entry you are trying to write is as follows: hostname=c1sus2 system=c1sp2 This script will not overwrite existing entries in testpoint.par If this is an attempt to move an existing system from one host to another, please remove conflicting entry from testpoint.par file It seems that changing the model name and host did not change the node allocation, so will remove the previous entries in testpoint.par to see if that helps. After deleting the following lines [C-node62] hostname=c1lsc system=c1sup from the file "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par", the installation went fine and the above entries were replaced by [C-node62] hostname=c1sus2 system=c1sp2 BTW, I now believe the reason we had the node conflict earlier was bcos both models still had the same value of dcuid=62, so I think changing this value in our model file would be a better solution. Work is ongoing. 16451 Fri Nov 5 12:49:32 2021 ranaUpdateSUSSetting up suspension test model Please don't put it on c1sus2. Put it on the completely independent test stand as we discussed Wednesday. You must test the controller on the simplant and verify that they thing is stable and works, before putting it in the 40m network. 16457 Mon Nov 8 17:52:22 2021 Ian MacMillanUpdateSUSSetting up suspension test model [Ian, Tega] We combined a controler and a plant model into a single modle (See first attachment) called x1sus_cp.mdl in the userapps folder of the cymac in c1sim. This model combines 2 blocks: the controler block which is used to control the current optics and is found in cvs/cds/rtcds/userapps/release/sus/c1/models/c1sus.mdl further the control block we are using comes from the same path but from the c1sup.mdl model. This plant model is the bases for all of my custom plant models and thus is a good starting point for the testing. It is also ideal because I know it can beeasily altered into a my state-space plant model. However, we had to make a few adjustments to get the model up to date for the cds system. So it is now a unique block. These two library blocks are set in the userapps/lib folder on the cymac. This is the lib file that the docker system looks to when it is compiling models. For a quick overview see this. All other models have been removed from the MatLab path so that when we open x1sus_cp.mdl in MatLab it is using the same models it will compile with. We could not find the rtbitget library part, but chris pointed us to userapps, and we copied it over using: scp /opt/rtcds/userapps/trunk/cds/common/models/rtbitget.mdl controls@c1sim:/home/controls/simLink/lib. NOTE TO FUTURE IAN: don't forget that unit delays exist. Next step: now that we have a model that is compiling and familiar we need to make medm screens. We will use the auto mdl2adl for this so that it is quick. Then we can start adding our custom pieces one by one so that we know that they are working. We will also work with Raj to get an independent python model working. Which will allow us to compare the cds and python models. Attachment 1: x1sus_cp.png 16951 Mon Jun 27 13:39:40 2022 DeekshaUpdateElectronicsSetting up the MokuLab [Cici, Deeksha] On Friday Cici and I set up the Mokulab to take readings of our loop. The aim is to characterise the PZT, in a similar manner as before, by exciting the circuit using our input noise (a swept sine) and recording the corresponding changes in the output. We used the MokuLab to observe the beat note created by the signals of the AUX and PSL, as well as the ASD of the output signal. The MokuLab simplifies the entire process. Pictured : The beat note as observed by Cici Attachment 1: WhatsApp_Image_2022-06-24_at_5.21.28_PM.jpeg 16073 Thu Apr 22 14:22:39 2021 gautamUpdateSUSSettings restored The MC / WFS stability seemed off to me. Trending some channels at random, I saw that the MC3 PIT/YAW gains were restored mixed up (PIT was restored to YAW and vice versa) in the last day sometime - I wasn't sure what other settings are off so I did a global burtrestore from the last time I had the interferometer locked since those were settings that at least allow locking (I am not claiming they are optimal). How are these settings being restored after the suspension optimization? If the burtrestore is randomly mixing up channels, seems like something we should be worried about and look into. I guess it'd also be helpful to make sure we are recording snapshots of all the channels we are changing - I'm not sure if the .req file gets updated automatically / if it really records every EPICS record. It'd be painful to lose some setting because it isn't recorded. Unconnected to this work - the lights in the BS/PRM chamber were ON, so I turned them OFF. Also unconnected to this work, the summary pages job that updates the "live" plots every half hour seem to be dead again. There is a separate job whose real purpose is to wait for the data from EOD to be transferred to LDAS before filling in the last couple of hours of timeseries data, but seems to me like that is what is covering the entire day now. Attachment 1: MCdamping.png 16078 Thu Apr 22 15:36:54 2021 AnchalUpdateSUSSettings restored The mix up was my fault I think. I restored the channels manually instead of using burt restore. Your message suggests that we can set burt to start noticing channel changes at home point and create a .req file that can be used to restore later. We'll try to learn how to do that. Right now, we only know how to burt restore using the existing snapshots from the autoburt directory, but they touch more things than we work on, I think. Or can we just always burt restore it to morning time? If yes, what snapshot files should we use? 16079 Thu Apr 22 17:04:17 2021 gautamUpdateSUSSettings restored Indeed, you can make your own snapshot by specifying the channels to snap in a .req file. But what I meant was, we should confirm that all the channels that we modify are already in the existing snapshot files in the autoburt dir. If it isn't, we should consider adding it. I think the whole burt system needs some cleaning up - a single day of burt snapshots occupies ~400MB (!) of disk space, but I think we're recording a ton of channels which don't exist anymore. One day...  Quote: Your message suggests that we can set burt to start noticing channel changes at home point and create a .req file that can be used to restore later. We'll try to learn how to do that. Right now, we only know how to burt restore using the existing snapshots from the autoburt directory, but they touch more things than we work on, I think. Or can we just always burt restore it to morning time? If yes, what snapshot files should we use? 10163 Wed Jul 9 12:01:43 2014 AkhilConfigurationElectronicsSetup Plan for placing the Frequency Counter inside the lab Today, me and Manasa went inside the lab to figure out a place for the place for the FC. The whole setup will be placed in a chassis box . The chassis in figure(setupforFC.pdf) will be placed in the highlighted(red) box in the figure(setup.png). All the cables will be routed to the computers from behind the box and the RF cables from the beat box will be routed from the front end of the box. The two raspberry Pi boxes will be placed inside the box and the Frequency counters will be mounted as shown so that the frequency count can be seen from outside. Attachment 1: setup.png Attachment 2: SetupFC.png 10129 Fri Jul 4 09:17:13 2014 AkhilConfigurationElectronicsSetup Used for Characterization of Frequency Counter Goal: To complete the characterization of the Mini Circuits UFC-6000 RF Frequency Counter to be used for beat note measurement as a part of frequency offset locking loop. The aim of this setup was to obtain the bode plots and PSD plots for the FC. Detail about the Setup: UFC RF Frequency Counter: Described in detail in one of my previous elog (http://nodus.ligo.caltech.edu:8080/40m/10020) Raspberry PiRaspberry Pi will be running Raspbian which is a version of Linux, and not a RTOS. When sampling data at a certain frequency we want samples to occur at fixed time intervals corresponding to the sampling period. A normal operating system cannot provide us with this functionality, and there will be jitter (variation) in the time difference between consecutive samples. Whether this is an issue depends on how much jitter we have and what the specific application is. In our application(measuring phase and noise), the jitter has to be taken into consideration. Hence for data acquisition we need to sample with much more tightly defined sampling periods (reduced jitter) which can be done by providing an external timing standard(Like a square pulse of the frequency same as the sampling rate of the FC ). ADC : The ADC serves for two different conversion processes in the setup: 1) For converting modulating analog signal(from SRS 30 MHz Wave Generator) into digital signal for data analysis on Raspberry Pi. 2) To provide an external clock reference to the Raspberry Pi. Interfacing ADC(ADS1115) with Pi: ### Configuring the ADS1115 - Configuration Register In order to set the modes of operation defined above we must set the config register within the ADS1115. A register is simply a memory location within the chip. Registers are made up of bytes (8 bits) of data. Registers are typically either one or two bytes long. The bits are: Bit [15] This bit is used to start a conversion, by setting this bit to 1 a conversion is initiated. When reading the config register this bit remains equal to 0 while the conversion is carried out, and is set to 1 once the conversion is complete, we can monitor this bit to find the status of a conversion Bits [14:12] These bits set which pin to use as input to the ADC. Note that we can choose either single ended or differential mode through setting these bits. Note that each configuration has two inputs AIN~p~ and AIN~n~. By setting AIN~n~ to GND we obtain a single ended input with AIN~p~ as the input. Bits [11:9] These bits set which setting of the programmable gain amplifier to use Bit [8] Continuous conversion / No Continuous conversion Bits [7:5] Set the samples per second (sps) value Bit [4:2] Comparator setup, we will not use the comparator so these bits are irrelevant Bit [1:0] Comparator mode, set to 11 to disable the comparator. Four channels are used in differential mode for A-D conversion of two analog signals, one the slow modulating signal input and the other for a square signal of 10 Hz (same as sampling rate of FC(0.1 s)). The raspberry Pi reads the external trigger from ADC and starts reading input from the FC only when the square signal is 1. Thus in this way we can avoid the clock jitter and timing can be as accurate as the RTOS. Function Generators: Three function generators are used in the setup: 1. IFR Marconi Generator used for RF Carrier signal. 2. SRS 30 MHz Function Generator used for slow modulating signal (upto 5Hz). 3. SRS 30 MHz signal for square wave used as clock(10 Hz). The setup is attached as pdf. The computer scripts will follow this elog. Measurements Taken: The input and output modulated signals are recorded and the delay and noise of the FC are to be estimated. Attachment 1: setup.pdf 10137 Mon Jul 7 13:56:13 2014 AkhilConfigurationElectronicsSetup Used for Characterization of Frequency Counter When I was trying to plot PSD of the measurements, I still couldn't get better resolution. There still seems to be a problem with timing and synchronization of the R Pi with the FC even after addition of the external trigger circuit. Now, I am looking to debug this issue. Attached are the plots showing missing data points and data from the FC at uneven spacing(zoomed in plot). Attachment 1: FreqVsTime.png Attachment 2: Missing_Data.png 2923 Wed May 12 12:58:26 2010 josephbConfigurationCDSSetup fb to handle lsc, lsp models on megatron I modified /cvs/cds/caltech/target/fb and changed the line "set controller_dcu=10" to "set controller_dcu=13" (where 13 is the lsc dcu_id number). I also changed the set gds_server line from having 10 and 11 to 13 and 14 (lsc and lsp). The file /cvs/cds/caltech/fb/master was modified to use C1LSC.ini and C1LSP.ini, as well as tpchn_C2.par (LSC) and tpchn_C3.par (LSP) testpoint.par in /cvs/cds/caltech/target/gds/param was modified to use C-node1 and C-node2 (1 less then the gds_node_id for lsc and lsp respectively). Note all the values of gds_node_id, dcu_id, and so forth are recorded at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/Existing_RCG_DCUID_and_gds_ids 7311 Wed Aug 29 19:28:41 2012 Elli KingUpdateLSCSetup for a cavity scan or the input mode cleaner Riju, Elli Today we prepared our experimental setup to take a cavity scan of the input mode cleaner, which we want to measure in the next day or so. Attached is a diagram of our setup. What we want to do is to inject a set of sidebands into the PSL and sweep their frequency from 32-45 MHz (a range just over one fsr of the mode cleaner- vfsr=11MHz). We will measure the power transmitted out of the MC using a photo-diode and demodulate this signal with our input signal from the Marconi. From this we should be able to see the resonant frequencies of the carrier and the higher order modes. One aspect we spent some time thinking about; whether we would be able to inject a signal into an EOM given the EOM and the Marconi are not perfectly impedance matched. Based on Kiwamu’s previous e-log entries designing the EOM, we decided that injecting a signal in 32-45 MHz region at 15dBm is similar to injecting the 29.5MHz sideband (at the same power level with very similar input impedance.) Fingers crossed we don’t blow anything up first week on the job. Attachment 1: 40m_cavity_scan_diagram.jpg 7312 Wed Aug 29 20:43:23 2012 KojiUpdateIOOSetup for a cavity scan or the input mode cleaner The technique is based on detection of the beating between the resonant carrier and a resonant higher order mode. This means that the beat signal is cancelled out if the transmitted beam is integrated over the entire beam. Thus, you may want to introduce intentional clipping (or cutting a half of the beam with a razor blade). I am quite curious on the measurement as I am going to do the same measurement for the aLIGO OMC. I am interested in seeing the statistical evaluation on the precision of the measurement. 10829 Mon Dec 22 15:46:58 2014 KurosawaSummaryIOOSeven transfer functions IMC OL TF has been measured from 10K to 10M Attachment 1: MC_OLTF.pdf 10832 Mon Dec 22 21:53:08 2014 rana, kojiUpdateIOOSeven transfer functions Today we were looking at the MC TFs and pulled out the FSS box to measure it. We took photos and removed a capacitor with only one leg. Still, we were unable to see the weird, flat TF from 0.1-1 MHz and the bump around 1 MHz. Its not in the FSS box or the IMC servo card. So we looked around for a rogue Pomona box and found one sneakily located between the IMC and FSS box, underneath some cables next to the Thorlabs HV driver for the NPRO. It was meant to be a 14k:140k lead filter (with a high frequency gain of unity) to give us more phase margin (see elog 4366; its been there for 3.5 years). From the comparison below, you can see what the effect of the filter was. Neither the red nor purple TFs are what we want, but at least we've tracked down where the bump comes from. Now we have to figure out why and what to do about it. * all of the stuff above ~1-2 MHz seems to be some kind of pickup stuff. ** notice how the elog is able to make thumbnails of PDFs now that its not Solaris! Attachment 1: MC_OLG.pdf 10833 Tue Dec 23 01:55:35 2014 rana, kojiUpdateIOOSeven transfer functions Some TFs of the TTFSS box Attachment 1: MC_FSS_TF.pdf 10841 Tue Dec 23 20:50:39 2014 rana, kojiUpdateIOOSeven transfer functions Today we decided to continue to modify the TTFSS board. The modified schematic can be found here: https://dcc.ligo.org/D1400426-v1 as part of the 40m electronics DCC Tree. What we did 1) Modify input elliptic filter (L1, C3, C4, C5) to give zero and pole at 30 kHz and 300 kHz, respectively. L1 was replaced with a 1 kOhm resistor. C3 was replaced with 5600 pF. C4 and C5 were removed. So the expected locations of the zero and pole were at 28.4 kHz and 256 kHz, respectively. This lead filter replaces the Pomona box, and does so without causing the terrible resonance around 1 MHz. 2) Removed the notch filters for the PC and fast path. This was done by removing L2, L3, and C52. At this point we tested the MC locking and measured the transfer function. We successfully turned up the UGF to 170kHz and two super-boosts on. 3) Now a peak at 1.7MHz was visible and probably causing noise. We decided to revert L2 and adjusted C50 to tune the notch filter in the PC path to suppress this possible PC resonance. Again the TF was measured. We confirmed that the peak at 1.7MHz is at -7dB and not causing an oscillation. The suppression of the peak is limited by the Q of the notch. Since its in a weird feedback loop, we're not sure how to make it deeper at the moment. 4) The connection from the MC board output now goes in through the switchable Test1 input, rather than the fixed 'IN1'. The high frequency gain of this input is now ~4x higher than it was. I'm not sure that the AD829 in the MC board can drive such a small load (125 Ohms + the ~20 Ohms ON resistance of the MAX333A) very well, so perhaps we ought to up the output resistor to ~100-200 Ohms? Also, we modified the MC Servo board: mainly changed the corner frequencies of the Super Boost stages and some random cleanup and photo taking. I lost the connecting cable from the CM to the AO input (unlabeled). 1. The first two Super Boost stages were changed from 20k:1k to 10k:500 to give us back some phase margin and keep the same low freq gain. I don't really know what the gain requirement is for this servo here at the 40m. The poles and zeros were chosen for iLIGO so as to have the frequency noise be 10x less than the SRD at 7 kHz. 2. The third Super Boost (which we never used) was changed from 10k:500 to ~3k:150 (?) just in case we want a little more low freq gain. 3. There was some purple vestigial wiring on the back side of the board with a flying resistor; I think this was a way to put a DC offset in to the output of the board, but its not needed anymore so I removed it. Attachment 1: MC_OLTF.pdf Attachment 2: MC_OLTF2.pdf Attachment 3: matlab.zip 1203 Wed Dec 24 10:33:24 2008 YoichiUpdateComputersSeveral fixes. Test point problem remains. Yesterday, I fixed several remaining problems from the power failure. I found a LEMO cable connecting the timing board to the Penteks was lose on the c1susvme1 crate. After I pushed it in, the DMA error has not occured on c1susvme1. I logged into op340m using a Null Modem Cable. The computer was failing to boot because there were un-recoverable disk errors by the automatic fsck. I run fsck manually and corrected some errors. After that, op340m booted normally and now it is working fine. Here is the serial communication parameters I used to communicate with op340m: >kermit (I used kermit command for serial communication.) >set modem type none >set line /dev/ttyS0 (ttyS0 should be the device name of your serial port) >set speed 9600 >set parity none >set stop-bits 1 >set flow-control none >connect  After fixing op340m, the MC locked. Then I reset the HV amps. for the steering PZTs. Somehow, the PZT1 PIT did not work. But after moving the slider back and forth several times, it started to work. I reset the mechanical shutters around the lab. I went ahead to align the mirrors. The X-arm locked but the alignment script did not improve the arm power. I found that test points are not available. (diag said test point management not available). Looks like test point manager is not running. Called Rolf, but could not reach him. I'm not even sure on which machine, the tp manager is supposed to be run. Is it c0daqawg ? 5183 Thu Aug 11 06:45:14 2011 NicoleSummarySUSShaking Testing Koji and I have finished shaking the table for the first round of measurements (horizontal shaking). We have cleaned up the lab space used. The FFT Analyzer has been put back to its position at the back side of the rack (near the seismometers). I will calibrate the photosensor for the suspension frame and piece together/analyze/produce graphs of the data today. If everything is fine (the measurements are fine) and if there is a chance, we hope to shake the TT suspension vertically. 17044 Thu Jul 28 16:51:55 2022 TegaUpdateBHDShaking test for LO beam AS beam to BHD DCPDs [Yuta, Tega, Yehonathan] To investigate the BHD power imbalance and clipping issues, we did some shaking test of the mirrors in the LO path and AS paths. The results suggests the following: • The clipping is happening after the BHD BS in DCPD_A path, as opposed to our initial guess of BHD BS transmission clipping in elog 17040. • The LO beam we are seeing is probably a ghost beam from PR2 We performed both PIT and YAW shaking of all mirrors and looked at the output at DCPD_A and DCPD_B, see table below for details. Since we only see the dithering signal in DCPD_A, it suggests that the clipping is ocurring after the BHD BS and is also confined to the path between BHD BS and DCPD_A. We also swapped the camera location from DCPD_A to DCPD_B on ITMY table and confirmed that the beam was clipped for DCPD_A but not for DCPD_B. This result discounts the possiblity of clipping being responsible for the power imbalance and therefore suggests that the power imbalance may actually be due to BHD BS not being 50:50. From the measurement in elog 17040, the transmission of BHD BS is 44$\pm$0.3% and the reflectivity is 56$\pm$0.3%. Note that DCPD_A is the transmission of BHD BS for AS beam, whereas DCPD_B is the reflection of BHD BS for AS beam, elog 16932. We expect the shaking of PR2 to give no signal in either DCPD_A or DCPD_B when the LO beam is purely in trasmission, however, we see a signal in DCPD_A sugesting that the LO beam transit path through PR2 may not be as expected, i.e. the beam might be exiting the side of PR2 instead of the AR coated surface. Finally, we measured the coherence between the dithering dof and DCPD_A/B & POP, see attachment 2, where we noticed that both DCPD_A/B have high coherence in the 1Hz-10Hz frequency band whereas ther was no coherence in POP as expected. This suggests that there may also be some small clipping in DCPD_B path. LO Beam Shaking (LO1, LO2, PR2):  color OPTIC DOF Freq OSC Amp (cnts) comment Black 0 Reference Blue LO1 YAW 304.4 2000 Signal in DCPD_A & No signal in DCPD_B Orange LO1 PIT 304.4 2000 No signal Magenta LO2 YAW 312.2 10000 No signal Purple LO2 PIT 312.2 10000 Signal in DCPD_A & No signal in DCPD_B Green PR2 YAW 308.8 20000 Signal in DCPD_A & No signal in DCPD_B Red PR2 PIT 308.8 20000 Signal in DCPD_A & No signal in DCPD_B AS Beam Shaking (AS1 and AS4)  color OPTIC DOF Freq OSC Amp (cnts) comment Black 0 Reference Blue AS1 YAW 305.5 2000 Signal in DCPD_A & No signal in DCPD_B Orange AS1 PIT 305.5 2000 Signal in DCPD_A & No signal in DCPD_B Magenta AS4 YAW 313.3 2000 Signal in DCPD_A & No signal in DCPD_B Purple AS4 PIT 313.3 2000 No signal Attachment 1: Screenshot_2022-07-28_16-58-34_LOandASShaking.png Attachment 2: Screenshot_2022-07-28_18-08-55_DCPDPOPSuspensionCoherence.png 17045 Thu Jul 28 20:16:26 2022 AnchalUpdateBHDShaking test for LO beam AS beam to BHD DCPDs Some insights from the inside vacuum situation: • The beam is an incident near normal on PR2 close to the center of the optic. It wasn't hard to align this part, I'm very confident that we aligned it to the center of PR2. So I do not think the LO beam is ghost beam from PR2. • The place that is most susceptible to clipping is POP_SM5 mirror in front of LO1. The LO beam has little clearance from the edge of the mirror. • Another possibility of clipping in LO beam is through the cage of LO2. LO2 is a 45-degree incidence mirror, so it is possible we are clipping off the cage or seeing a ghost beam mixed in LO beam here. • The fact that moving PR2 is affecting LO beam is weird but doesn't necessarily mean it is a ghost from PR2. 3734 Mon Oct 18 11:22:13 2010 JenneUpdateComputersShame on people not elogging! FrameFiles backups not working. On the one hand, SHAME ON ALL PEOPLE WHO DON'T ELOG THINGS, such as the moving of scripts directories (it was a pain to figure out that that's part of why the backup scripts are broken). On the other hand, the moving of the scripts directories brought to light a critical problem in the backup scheme. None of the frame files have been backed up since Joe replaced fb40m with fb, on ~23 Sept (I think). What went down: The frame builder was replaced, and no backup script was started up on the new machine. Sadface. Crontab doesn't work yet on the new machine, and also the 'ssh-add' commands give an error: controls@fb /cvs/cds/rtcds/caltech/c1/scripts/backup ssh-add ~/.ssh/id_rsa
No such file or directory
controls@fb /cvs/cds/rtcds/caltech/c1/scripts/backup ssh-add ~/.ssh/backup2PB No such file or directory  Thus, I know that the backup was never running on the new fb. However, the check-er script runs on nodus, and looks at the logfile, and since there was no script running, it wasn't adding to the log file, so the last log was an "Okay, everything worked" entry. So, the check-er script kept sending me daily emails saying that everything was okie-dokey. Since all of the scripts were moved (Joe said this happened on Friday, although there's no elog about it), the check-er script, and all of the rest of the backup scripts point to the wrong places (the old scripts/backup directory), so I didn't receive any emails about the backup either way (usually it at least sends a "Hey, I'm broken" email). This clued me in that we need to check things out, and I discovered that it's all gone to hell. Since I can't add the ssh clients to the new fb, I can't actually log in to the backup computers over in Powell-Booth to check when the last legitimately successful backup was. But I suspect it was just before the fb was replaced. So, we need to get Crontab up and running on the new Frame Builder machine so that we can run cron jobs, and we also need to figure out this backup hullabaloo. I think I'll email / call Dan Kozak over in downs, who was talking about upgrading our backup scheme anyway. 13906 Thu May 31 22:59:27 2018 KojiConfigurationComputersShorewall on nodus [Jonathan Koji] Shorewall (http://shorewall.net/), a tool to configure iptables, was installed on nodus. The description about shorewall setting on nodus can be found here: https://wiki-40m.ligo.caltech.edu/NodusShorewallSetting NDS (31200) on megatoron is not enabled outside of the firewall yet. 3084 Thu Jun 17 17:09:44 2010 AlbertoUpdateLSCShort Cavity Length Adjustments I calculated the phase shifts that the sidebands would pick up in the arms in the case we changed the arm length to 38.4m as proposed. I obtained the following values (in degrees): phi(-f2) = 0.66; phi(-f1) = -0.71; phi(f1) = 0.71; phi(+f2) = -0.66 These are the plots with the results as I obtained from an Optickle simulation (the second zooms in around 38.4m). These values agree with what Koji had already estimated (see elog entry 3023). Since we can't make the arm longer than that, to increase the distance from the resonance, we would like to adjust the length of the short cavities to compensate for that. For f2 (=55MHz), 0.7 degrees correspond to about 5cm. That is about the length change that we expect to make to the design. I simulated with Optickle the effect of changing the length of either the SRC or the PRC. The best way I found to do that, was to measure the cavity circulating power when the macroscopic lengths change. The following plots show the effect of changing either the PRC or SRC length (left or right figure), on the circulating power of both cavities at the same time (top and bottom plots). You can compare these with the case of perfect antiresonance as in the following plots: It seems that the design length for the short cavities are not too bad. f1 is not optimized in the PRC, but changing the length of the cavity wold just make f2 worse in SRC. These simulations seem to support the choice of not changing the design cavity lengths for PRC and SRC. Of course these are only an "open loop" simulations. At the moment we don't know what would be the effect of closing the control loops. That is something I'm going to do later. It'll be part of my studies on the effects of cavity absolute length on the whole IFO. 3086 Fri Jun 18 13:47:20 2010 KojiUpdateLSCShort Cavity Length Adjustments You should have been in my lecture yesterday! Power in the cavity is not a good index (=error signal) to judge the optimal length. You should look at the phases of the length signals. (i.e. demodulation phase which gives you the maximum amplitude for CARM, PRC, SRC, etc) You must move the SRC and PRC lengths at the same time. The resonance of f1 (mostly) depends on the PRC length, but that of f2 depends on both the PRC and SRC lengths. 3087 Fri Jun 18 15:07:26 2010 AlbertoUpdateLSCShort Cavity Length Adjustments  Quote: You should have been in my lecture yesterday! Power in the cavity is not a good index (=error signal) to judge the optimal length. You should look at the phases of the length signals. (i.e. demodulation phase which gives you the maximum amplitude for CARM, PRC, SRC, etc) You must move the SRC and PRC lengths at the same time. The resonance of f1 (mostly) depends on the PRC length, but that of f2 depends on both the PRC and SRC lengths. Right. Ultimately the phase gain inside the cavity is what we look at. Calculating that for the SBs inside PRC and SRC is actually the first thing I did. But I kept getting very small angles. Too small, I thought. Maybe there was some problem in the way I calculated it. Then I made a power analysis to check if the SBs were getting affected at all by that 0.7degree phase shift they're picking up in the arms. I wanted to show the point where I am, before leaving. But, I keep working on it. 1089 Fri Oct 24 21:49:15 2008 JenneConfigurationPEMShort Seismometer Cable Bad news regarding the cable that goes between the Guralp seismometer and the box that I've been working on: it's too short by about a factor of 2. Dang it. I've placed the seismometer underneath the Beam Splitter Chamber (where it needs to go), and started running the cable toward the ADC rack where box was planned to go, and as Rana guessed earlier tonight, the cable isn't nearly long enough. We have some options: the seismometer can go back into the half-height rack near the BS, SRM, PRM oplev's optical table where I think it used to be, or it can go into the rack with the Kepco high voltage power supplies and the laser's supply. The cable won't reach any farther than that. I think that we can just add BNC extensions onto the octopus cable that Bob made for the Guralp box, so all we need to figure out after we decide on a rack is the power for the box. 2219 Mon Nov 9 16:32:36 2009 AlbertoFrogsEnvironmentShot of the white board yesterday before erasing Yesterday Rana and I needed some room on the white board in the Control Room. We had to erase some of the stuff present on the board despite the bif warning "Do Not Erase". This is how it looked like before erasing. Attachment 1: DSC_0980.JPG 16884 Wed Jun 1 11:56:28 2022 yutaUpdateALSShutter driver for GRY replaced [JC, Yuta] We replaced a shutter driver for GRY since it stopped working this morning. We replaced it with a free driver which was sitting on the ITMY table. The reverse polarity issue of C1:AUX-GREEN_Y_Shutter was fixed by switching one of the switches of the driver from N.O. to N.C. Also, "Toggle" button was added to IFO_ALIGN.adl so that we can toggle shutters easily to find TEM00. It runs /home/controls/Git/40m/scripts/ALS/ShutterToggler.py.  Quote: The green Y shutter now works but in reverese, meaning that sending 1 to C1:AUX-GREEN_Y_Shutter closes the shutter and vice versa. This needs to be fixed. Attachment 1: Screenshot_2022-06-01_12-01-53.png 11386 Wed Jul 1 09:33:31 2015 KojiUpdateGeneralShutters closed, watch dogs disabled for the RCG upgrade I closed the PSL/GREEN shutters and shut off the LSC feedback/SUS watch dogs at 9AM PDT, to allow Jamie to start his disruptive work. 4837 Mon Jun 20 09:28:19 2011 JamieUpdateCDSShutting down low-voltage DC power in 1X1/1X2 racks In order to install the BO module in 1X2, I need to shut down all DC power to the 1X1 and 1X2 racks. 11073 Thu Feb 26 01:51:39 2015 ericqUpdateLSCSideband HOMs So, my previous post suggested that 44*11 products might be the dominating signals in our "nominal" setup. I suppose that this could be not so bad, since it's not too unlike -11*22; the 11MHz field couples into the PRC and reflects with a rapidly changing phase around PRC resonance, and 44MHz is antiresonant, so it is a good local oscillator for REFL33. However, it then occured to me that my previous HOM analysis only looked at the 11MHz and 55MHz sidebands. When extending this to all of the sidebands within 55MHz, I discovered a troubling fact: With the IFO parameters I have, the second spatial order +22MHz and fourth spatial order +44MHz fields almost exactly coresonate with the carrier in the PRFPMI! (DR, too) If this is true, then any REFL33 signal seems to be in danger if we have an appreciable amount of these modes from, say, imperfect modematching. On the other hand, we've been able to hold the PRMI with REFL33 when ALS is "on resonance," so I'm not sure what to think. (As a reminder, this analysis is done with analytic formulae for the complex reflectivities of the arm cavities and coupled recycling cavities as a function of CARM, spatial order and field frequency. Source is attached.) It seems the Y arm geometry is to blame for this. Maybe we should try to measure/confirm the Y arm g-factor... Attachment 1: C1_HOMcurves_PR.png Attachment 2: C1_HOMcurves_Y.png Attachment 3: C1_HOMcurves_X.png Attachment 4: C1_HOMlist.zip 12234 Thu Jun 30 16:21:32 2016 gautamUpdateCOCSideband HOMs resonating in arms [EricQ, gautam] Last night, we set about trying to see if we could measure and verify the predictions of the simulations, and if there are indeed HOM sidebands co-resonating with the carrier. Koji pointed out that if we clip the transmitted beam from the arm incident on a PD, then the power of the higher order HG modes no longer integrate to 0 (i.e. the orthogonality is broken), and so if there are indeed some co-resonating modes, we should be able to see the beat between them on a spectrum analyzer. The procedure we followed was: 1. Choose a suitable PD to measure the beat. We chose to use the Thorlabs PDA10CF because it has ~150MHz bandwidth, and also the responsivity is reasonable at 1064nm. 2. We started our measurements at the Y-end. There was a sufficiently fast lens in the beam path between the transmon QPD and the high gain PD at the Y end, so we went ahead and simply switched out the high gain thorlabs PDA520 for the PDA10CF. To power the PDA10CF, we borrowed the power cable from the green REFL PD temporarily. 3. We maximized the DC power of the photodiode signal using an oscilloscope. Then to introduce the above-mentioned clipping and orthogonality-breaking, we misaligned the beam on the PD until the DC power was ~2/3 the maximum value. 4. We then hooked up the PD output to the Agilent network analizyer (with a DC block). 5. We measured the spectrum of the PD signal around 11.066MHz (with 100kHz span) and higher harmonics up to 55MHz and used a narrow bandwidth (100Hz) and long integration time (64 averages) to see if we could find any peaks. More details in the results section. 6. Having satisfied ourselves with the Y-end measurements, we • restored the power cable to the green beat PD • re-installed the thorlabs PDA520 • verified that both IR and green could be locked to the arm We then repeated the above steps at the X-end (but here, an additional lens had to be installed to focus the IR beam onto the PDA10CF - there was, however, sufficient space on the table so we didn't need to remove the PDA520 for this measurement). Results: Y-end: DC power on the photodiode at optimal alignment ~ 200mV => spectra taken by deliberately misaligning the beam incident on the PD till the DC power was ~120mV (see remarks about these values). RF sideband (Y-arm) Peak height (uV) Beat power (nW) RF sideband (X-arm) Peak height (uV) Beat Power (nW) 11 1.55 0.52 11 1.2 0.4 22 10.6 3.53 22 none seen N.A. 33 none seen N.A. 33 none seen N.A. 44 22.0 7.33 44 7 2.33 55 8.6 2.97 55 5 1.67 I converted the peak heights seen on the spectrum analyzer in volts to power by dividing by transimpedance (=5*10^3 V/A into a 50ohm load) * responsivity at 1064nm (~0.6A/W for PDA10CF). Remarks: 1. This effect flagged by the simulations seems to be real. Unfortunately I can't get a more quantitative picture because we can't quantify the mode-overlap between the carrier 00 mode and any higher order mode on the beat PD (as we know nothing about the profile of these modes), but the simulations did suggets that the 2nd order 22MHz and 4th order 44MHz HOMs are the ones closest to the carrier 00 resonance (see Attachments #2 and #3), which is kind of borne out by these results. 2. I disbelieve the conversions into power that I have done above, but have just put them in for now, because a DC power of 200mW at the Y-end suggests that there is >160uW of light transmitted from the arm, which is at least twice what we expect from a simple FP cavity calculation with the best-known parameters. If I've missed out something obvious in doing this conversion, please let me know! 3. For the Y-arm, the region around 55MHz had a peak (presumably from the sideband HOM beating with the carrier) but also a bunch of other weird sub-structures. I'm attaching a photo of the analyzer screen. Not sure what to make of this... Attachment 1: image.jpeg Attachment 2: C1_HOMcurves_Y.pdf Attachment 3: C1_HOMcurves_X.pdf 3360 Wed Aug 4 16:52:59 2010 Razib, AidanUpdatePhase CameraSideband power measurement (updated) Aidan and I made some attempt to measure the power of the sidebands so that we can calculate our expected signal strength. Our setup looks like the following: As light from the laser is split into two at BS1, the transmitted beam has higher power as our BS1 is only coated for 1064nm. We get two reflected beams from BS1, one reflected of the front surface and the other from the back surface. We took the stronger back reflected beam to the EOM driven at 40 MHz (also at 25 MHz at a later time). The AOM produced a reference beam with 40 .000 005 MHz offset which we recombined with the sidebands obtained from the EOM. The beat produced is sent off to PDA 10CF connected to 4395A spectrum analyzer. The plots for 40MHz sidebands and 25 MHz sidebands looks like this: From the above spectra, at 40 MHz sideband regime: Power of the carrier @ 40 MHz = -39.72 dBm Power of the sideband @ 80 MHz = -60.39 dBm At 25 MHz sideband regime, Power of the carrier @ 40 MHz = -40.22 dBm Power of the upper sideband @ 65 MHz = -61.72 dBm Power of the lower sideband @ 15 MHz = -60.99 dBm Power Measurement: We made some necessary power measurement using a PD connected to a voltmeter after the EOM and the AOM when the EOM is driven at 40 MHz: ___________________________________________________________ Dark : 0.025 V AOM on: 4.10 V (EOM blocked) EOM : 2.425 V (AOM blocked) ___________________________________________________________ From the earlier calculation (ref: Elog entry July 28) the power that we expect to see at the PD is, P= A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2 +2* A_r* A_sb * cos ( w_(r,sb) t ) , where A_c= carrier; A_r= reference beam; A_sb=Upper sideband; A_(-sb)= Lower sideband, w_(r,sb) = w_r - w_sb P = A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2 +2* A_r* A_sb , letting cos (w_(r,sb) go to 1) is order to approximate the maximum signal So the signal that we expect to see relative to the DC ( i.e A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2, the first four terms of the power equation) is, Sig = 2* A_r* A_sb / { A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2 }, Since the modulation index is small, the power in the sideband is very small compared to carrier and the reference beam. So we can ignore the sideband power for the signal expression. So, Sig = 2* A_r* A_sb / ( A_c ^2 + A_r^2 ) So if we want to maximize this signal w.r.t the reference then, d (sig)/ d(A_r) = 2 { ( A_c ^2 - A_r^2) *A_sb } / {( A_c^2 + A_r^2)} ^2 Thus, the signal is maximized when, A_r^2 = A_c^2 We adjusted the AOM to be driven at + 7.7 dBM so that the new power at the AOM matched the EOM power, which is 2.397 in the voltmeter. So the power at both the AOM and the EOM are: P_AOM = ( V_AOM - V_dark) / (PD responsitivity * Transimpedance gain) = ( 2.397 - 0.025 ) / ( 0.45 * 1.5 x 10 ^5 ) = 3.51 x 10 ^ - 5 W P_EOM = (V_EOM - V _dark) / (PD responsitivity * Transimpedance gain) = ( 2. 425 - .0.025) / ( 0.45 * 1.5 x 10 ^5 ) = 3.55 x 10^ - 5 W From the spectra of the 40 MHz sideband above, the ratio of the carrier and the sideband amplitude is: A_c / A_sb = 10.8 . P_EOM = A_c ^2 + 2 A_sb ^2 Therefore, A_sb = sqrt ( P_EOM / 118.64) = 5.47 x 10^ - 4 V/m Thus, A_c = 5.908 x 10^ -3 V/m and A_r = sqrt ( P_AOM) = 5.92 x 10 -3 V/m. This measurement can be used to calculate the signal to contrast ratio (SCR) that we expect to see: SCR = 2 A_r * A_sb / ( A_c^2 + A_r^2 ) = 0.09 Our next step is to measure the actual signal to constrast ratio as seen by the camera. Details of that will be posted soon. 3411 Thu Aug 12 16:52:02 2010 RazibUpdatePhase CameraSideband power measurement (updated) I made some measurement of the SCR (signal to contrast ratio) from the signal from the EOM and the AOM. The recipe for that was: 1. Trigger the camera at 20 Hz (from function generator). 2. Take a series of 20 images. 3. Do FFT to take out the DC component. 4. Extract the beat signal out of the FFT'd data. 5. Block the EOM. 6. Take another set of images of the AOM beam. 7. Take more(!) images, but this time of the background (blocking both EOM and AOM). So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry. The plot for that is: After measuring the SCR, I also measured the amplitude of the sideband and made an amplitude profile of the 40 MHz sideband. The amplitude measurement is done as follows: We know that the our 5 Hz signal consists of, Sig = A_r * A_sb where A_r = amplitude of the reference beam, A_sb= amplitude of the sideband So, A_sb = Sig / A_r . But, A_r = sqrt ( P_AOM - Background), Thus A_sb = Sig / sqrt( P_AOM - Background) . So the amplitude profile is done by taking the 5 Hz beat signal and dividing by the square root of the AOM beam minus the background light. The plots looks like this: The solo sideband profile looks like this: Next we plan to trigger the camera with a 1 KHz signal and take snaps at n* T/4 (where n=0,1,2,3) of the period of the beat signal. So the plan is to trigger the camera at the point where the red dots appear in following cartoon. Some more details of this setup will be posted later.  Quote: Attachment 4: sine_trig.jpg 3412 Thu Aug 12 17:10:07 2010 KojiUpdatePhase CameraSideband power measurement (updated) This sounds very relieving although this could be a lower bound of the number. Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR. Ed: I meant time series of the PD output  Quote: So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry. 3413 Thu Aug 12 17:28:28 2010 RazibUpdatePhase CameraSideband power measurement (updated) Quote: This sounds very relieving although this could be a lower bound of the number. Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR.  Quote: So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry. The SCR was at first measured using the output of the PD. That was exactly from where we got our 0.09 (previous elog entry). The second measurement was from the CCD. 6167 Wed Jan 4 05:02:58 2012 kiwamuUpdateLSCSidebands measurement at POP Just a quick report: I did the first attempt to measure the recycling gains of the sidebands in the DRMI configuration (sidebands resonant condition) by looking at the output of the POP22/110 RFPD. Because this time what I measured is some absolute values of the sidebands power, it doesn't tell us anything quantitatively until we calibrate it or compare it with similar data. So I need to measure the same things in some different configurations (e.g. PRMI, SRMI, etc.) in order to extract some useful information from the measurement. The attached picture is the display of a power spectrum analyzer looking at the output of the POP22/110 broadband RFPD while the DRMI (in the sideband resonant condition) was kept locked. You can see that 111 MHz (twice of 55 MHz) is prominent. Also there are several peaks at 11, 22, 44 and 66 MHz. 1297 Thu Feb 12 14:39:07 2009 ranaSummaryGeneralSilicon Beam Dump test Yesterday evening, Ken Mailand and I tested the reflectivity of a piece of polished Silicon. Since Silicon has such a high thermalconductivity (compared to stainless and fused silica) and can take much more heat than black glass and should have a very good BRDF and should absorb most of the 1064 nm light if we hit it at Brewster's angle, we want to try it out in the first version high power, low scatterbeam dump. This dump will be a 'V' style dump like what Steve has tested nearly a year ago, but the incoming beam will first hit this piece of Silicon. The pictures of the setup and the Silicon with the beam hitting it are here. Brewster's angle for p-pol at 1064 nm is 74.2 deg (n = 3.53 @ 1064 nm). We set up a cube polarizer on the output of the ~1064 nm CrystaLaser. 144 mW got to the Si; the reflected beam was ~1.9-2.0 mW after tuning the angle for minimum power. Via eyeball and protractor it seems that we're at ~74 deg. So the reflectivity is < 1.5-2%. This is good enough; the reflected power will be < 1 W in all cases for eLIGO and that can be absorbed by the rest of the stainless V dump. The 35 W of heat in the silicon will be mostly gotten rid of through conduction into the attached heat sink fins. This kind of dump would go into places like the PMC-REFL, MC-REFL, & IFO-REFL, where we occasionally need to take high power, but also are sensitive to backscatter. 2752 Thu Apr 1 16:34:29 2010 HartmutUpdateGreen LockingSilicon PDs just a few infos on Silicon PDs I looked up. If you want to go beyond the 100MHz achievable with the device I worked on, the one thing to improve is the opamp, where Steve is trying to find OPA657. This is a FET with 1.6GHz BWP, minimum stable gain of 7, and 4.8nV/rt(Hz) noise. Should be ok with 750-1000 Ohm transimpedance. The other thing you might want to change is the PD (although it might be the 1cm PD with high bias is as fast as smaller ones with lower bias). There are two types of other Si diodes at the 40m right now (~3mm): -Rana and I found a Centronic OSD 15-5T in the old equipment -Frank gave me a Hamamatsu S1223-01 on a Thorlabs pre-amp device (could be taken out). The Centronic OSD 15-5T has up to 80pF with 12 V bias according to the datasheet. The Hamamatsu S1223-01 is stated with 20pF only, but stated to have a max. frequency resp. of 20MHz ('-3db point'). I dont know what this means, as the corner freq. of 10pF into 50Ohm is still 160MHz. In any case there are faster 3mm types to start with, as for example Hamamatsu S3399 (~ 90),

which is stated to have the corner at 100MHz with 50 Ohm load.

For this type the stated capacity (20pF) looks consistent with ~100MHz corner into 50 Ohm.

So probably you can get higher BW with this one using much smaller load, as in transimpedance stage.

7181   Tue Aug 14 16:33:51 2012 SashaUpdateComputer Scripts / ProgramsSimPlant indicator added

I added an indicator to the watch dog screen so that a little "SP" icon appears whenever the SimPlant is on. Since we only have one simplant (ETMX), only ETMX has the simPlant indicator. However, since assymetry is ugly, I moved all of the OL icons over so that they're in a line and so that there is room for future SP icons.

I also fixed the link to the Watchdogs on the main SUS screens (it was dead, but now it is ALIVE).

4394   Thu Mar 10 01:28:47 2011 joe, jamie, rana, chrisSummaryCDSSimSuspension !

Today was a banner day for Simulated Plants.

Joe and Jamie have been working to get it all happening and this afternoon we started stuffing filters into the plant to make it act like the:

We put in the following features so far:

1. Anti-Imaging filters (these are hacked to be approximate since the real ones are 7570 Hz LP filters and the SimAI only can have filters up to 8192 Hz).
2. Dewhitening filters (copied from the SimDW in the SUS-ETMY screens)
3. Coil Driver transimpedance (1 / 200 Ohms)
4. Magnet-coil force constant (0.016 N/A)
5. Conversion from Coil to DOF Basis
6. All DOFs of the mechanical model are represented as simple harmonic oscillators with Q~100 and f ~ measured free swinging peaks.
7. Signals/Noise can be injected either as force noise on the test mass or as displacement noise at the suspension point.
8. Conversion from DOF to Shadow Sensor basis.
9. Optical Levers (with whitening)

We have also changed the switching logic for the SUS and SimETMs for the shadow sensor whitening. It used to be that either the hardware OR the software whitening was on. Now we have made it like all of the other whitening/antiwhitening in LIGO and the whitening/antiwhitening come on together. Joe and Jamie are going to propagate this to the other SUS. The hardware filter is a 30,100:3 (poles:zeros) whitening filter. The digital filter used to also be 30,100:3 with a DC gain = 1. I've changed the FM1 filter in the XXSEN filter banks into a 3:30 for the ETMY so that it now comes on and just compensates the hardware filter. This change should be propagated to all other SUS and the MEDM screens updated to show the new situation.

After this change, we decided to calibrate the {UL,UR,LL,LR,SD}SEN channels into units of microns. To do this we have made an FM6 filter called 'cts2um' that accounts for the OSEM gain and the ADC conversion factors. These channels are now in units of microns without applying any calibration in the DTT or Dataviewer. The plot below shows the OSEM shadow sensor time series with all damping loops ON and a very rough version of seismic noise being injected in all 6 DOFs (note that the y-axis is microns and the x-axis is seconds).

Next, Jamie is adding the angular calibrations (so that SUSPIT and SUSYAW are in rads) and Chris is making vectift quality seismic noise injectors.

We also need to add coating thermal noise, suspension thermal noise, substrate thermal noise, ADC/DAC noise and a lot of MEDM screen indicators of what state we're in. I myself can't tell from the OSEM time series if its real or Sim.

7151   Sat Aug 11 01:10:26 2012 SashaUpdateSimulationsSim_Plant Working!

Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise.

P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS?

Attachment 1: Plant_sen.jpg
7152   Sat Aug 11 18:05:49 2012 SashaUpdateSimulationsSim_Plant Working!

 Quote: Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise. P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS?

Developed some seismic noise. I adapted the seismic noise filters we used for the MC model way back when.  They looked questionable to begin with, but I added some poles/zeroes to make it more accurate (see Attached).

Attachment 1: seismic_noise1.jpg
7167   Mon Aug 13 23:06:08 2012 JenneUpdateSUSSimplant left on

Simplant for ETMX was left on, so I didn't have control of ETMX.  Not cool.  The IFO should be left in it's 'regular' state (all optics restored to saved alignments, no simplant, LSC/ALS/ASS loops off) if you're not actively working on it.

What this did point out, however, is that we need a big ol' indicator on the IFO_ALIGN / LSC / Watchdog / Overview screens to indicate that simplant is on for a particular optic, or whatever simplant might be controlling that takes away 'regular' control.  I probably would have continued being frustrated and confused for a lot longer if Eric didn't mention that simplant could have been left on.  Thanks Eric!

Symptoms, which perhaps would have eventually pointed me to simplant, were that there was some weird moving beam on the AS camera that was flashing fabry-perot fringes, and the POX signal looked like junk. After some looking around, I noticed that ETMX, while it claimed to have all the damping loops on, and the oplev on, was swinging a lot (rms levels of 4 - 7, rather than the usual < 2 ).  I said something out loud, and Eric suggested looking at Simplant.  After putting Simplant back to Reality, things are back to normal.

3276   Fri Jul 23 14:26:01 2010 GopalUpdateOptic StacksSimple Frequency Response Measurements in COMSOL

Over the past couple days, I discovered a simple, direct method for calculating frequency responses with a combination of COMSOL and any plotter such as Excel or MatLab. The simple case of rectangular prism of steel was analyzed using this method; details will be posted shortly on the COMSOL Wiki page. The frequency response matched theoretical reasoning: the bar acts as a simple mechanical low-pass filter, rapidly attenuating driving frequencies at the base beyond the first eigenmode.

It therefore shouldn't be too difficult to extend this analysis to the MC1/MC3 stack. The many eigenfrequencies will produce a more complicated transfer function, and so more data points will be taken.

The major shortcoming of this method involves dealing with the imaginary components of the eigenfrequencies. As of now, I haven't found a way of measuring the phase lag between the drive and the response. I also haven't found a way of changing the damping constants and therefore playing with phase components.

16718   Wed Mar 9 11:52:18 2022 YehonathanUpdateBHDSimplified BHD readout sketch on ITMY table

I have made an editable draw.io diagram of the planned simplified BHD setup on the ITMY table (see attached).  10 pts = 1 inch.

This is very sketchy but easily adjustable since we are removing everything but the ITMY Oplev from that table.

Attachment 1: ITMY_Table_Sketch.drawio.pdf
16719   Wed Mar 9 12:57:52 2022 KojiUpdateBHDSimplified BHD readout sketch on ITMY table

- BHD beams were already mixed in the chamber. So we don't need a BS on the table. (Probably there is no BS already)

- We don't need to split each BHD beam. One PD per BHD beam is OK for now.

- Check if the BHD paths have reasonable angles from the windows so that the beams do not hit the chamber wall.

- We need the POY path. POY indeed goes to the BS table

16755   Mon Apr 4 15:49:06 2022 TegaUpdateOptical LeversSimplified sketch on BS table

I have updated the BS table using feedback from Koji and Paco and the attached pdf document is the latest iteration.

Attachment 1: BS_Table.drawio.pdf
ELOG V3.1.3-