40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 228 of 344 Not logged in
ID Date Author Type Category Subject
17224   Thu Nov 3 16:00:58 2022 alexSummaryGeneralSensoray updates

I am currently working on getting the driver reinstalled on Donatella for the sensoray. An issue keeps arising that will not allow me to run "make" successfully in the unzipped driver folder. Will continue to remedy this.

This is why there is no light showing up on the device while plugged in. The computer does see the device, but does not show its model due to the inability for it to communicate without the driver.

-Alex

3545   Wed Sep 8 11:56:24 2010 kiwamuSummaryCDSSeptember CDS test plan

Joe and Kiwamu

We discussed about our CDS plan for this September. The summary of the plan and "to do list" are now on the wiki page;

Basically there are three major missions that we will do in this month;

1. complete damping of the vertex suspensions
2. Preparation for Green locking
3. Development of Simulated Plants

We also try to keep updating the wiki page.

14320   Mon Nov 26 21:58:08 2018 JonOmnistructure Serial Vacuum Signals

All the serial vacuum signals are now interfaced to the new digital controls system. A set of persistent Python scripts will query each device at regular intervals (up to ~10 Hz) and push the readings to soft channels hosted by the modbus IOC. Similar scripts will push on/off state commands to the serial turbo pumps.

Each serial device is assigned an IP address on the local subnet as follows. Its serial communication parameters as configured in the terminal server are also listed.

Device IP Address Baud Rate Data Bits Stop Bits Parity
MKS937a vacuum gauge controller 192.168.114.11 9600 8 1 even
MKS937b vacuum gauge controller 192.168.114.12 9600 8 1 even
GP307 vacuum gauge controller 192.168.114.13 9600 8 1 even
GP316a vacuum gauge controller 192.168.114.14 9600 8 1 even
GP316b vacuum gauge controller 192.168.114.15 9600 8 1 even
N2 pressure line gauge 192.168.114.16 9600 7 1 odd
TP2/3 192.168.114.17/18 9600 8 1 none

## Hardware Modifications

• Each of the five vacuum gauge controllers has an RJ45 adapter installed directly on its DB9/DB25 output port. Because the RJ45 cable now plugs directly into the terminal server, instead of passing through some additional adapters as it formerly did, it was necessary to reverse the wiring of the controller TXD and RXD pins to Ethernet pins. The DB9/25-to-RJ45 adapters on the back of the controllers are now wired as follows.
• For the MKS controllers: DB2 (RXD) --> Eth4;  DB3 (TXD) --> Eth5;  DB5 (RTN) --> Eth6
• For the Granville-Phillips controllers: DB2 (TXD) --> Eth5;  DB3 (RXD) --> Eth4;  DB7 (RTN) --> Eth6
• I traced a communications error with the GP307 gauge controller all the way back to what I would have suspected least, the controller itself. The comm card inside each controller has a set of mechanical relay switches which set the communications parameters (baud rate, parity, etc.). Knowing that this controller was not part of the original installation, but was swapped in to replace the original in 2009, I pulled the controller from the rack and checked the internal switch settings. Sure enough, the switch settings (pictured below) were wrong. In the background of the photo is the unit removed in 2009, which has the correct settings. After setting the correct communications parameters, the controller immediately began communicating with the server. Did these readouts (PRP, PTP1) never work since 2009? I don't see how they could.
Attachment 1: GP307_relays.jpeg
8745   Tue Jun 25 12:42:16 2013 gautamUpdateGeneralSerial-interface with Doubling Oven at Y end

Summary

I have been working on setting up a serial-link with the temperature controller of the PPKPT crystal doubling oven at the Y-end for some time now. The idea was to remotely tune the PID gains of the controller and get temperature data. The device used to serially interface with the temperature controller is a Raspberry Pi model B, which is connected to the temperature controller by means of a USB to serial adaptor with a PL2303 chip. I installed the interface this morning, and have managed get talking with the doubling oven. I am now able to collect time-series data by ssh-ing to the Raspberry Pi from the control room. I will use this data to manually tune the PID gains for now, though automatic tuning via some script is the long-term goal.

Details

The temperature controller for the doubling oven is a Thorlabs TC200, and supports serial communication via the RS232 protocol by means of a female DB9 connector located on its rear panel. I have hooked up the Raspberry Pi to this port by means of a USB-Serial adaptor that was in one of the cabinets in the 40m control room. After checking the Martian Host Table, I assigned the Raspberry Pi the static IP 192.168.113.166 so that I could ssh into it from the control room and test the serial-link. This morning, I first hooked up the Raspberry pi to an ethernet cable running from rack 1Y4 to make sure I could ssh into it from the control room. Having established this, I moved the raspberry pi and its power supply to under the Y-endtable, where it currently resides on top of the temperature controller. I then took down the current settings on the temperature controller so that I have something to revert to if things go wrong: these are

Set-Point:                           35.7 Celcius

Actual Temperature:          35.8

P-gain:                                 250

I-gain:                                 60

D-gain:                                25

TUNE:                                  ON

I then connected the Pi to the temperature controller using the serial-USB cable, and plugged the ethernet cable in. Rebooted the Pi and ssh-ed into it from the control room. I first checked the functionality of the serial-link by using terminal's "screen" feature, but the output to my queries was getting clipped on the command line for some reason (i.e. the entire output string wasn't printed on the terminal window, only the last few characters were). Turns out this is some issue with screen, as when I tried writing the replies to my queries to a text file, things worked fine.

At present, I have a python script which can read and set parameters (set-point temperature, actual temperature, PID gains)on the controller as well as log time-series data (temperature from the temperature sensor as a function of time )to a text file on the Pi. As of now, I have only checked the read functions and the time-series logger, and both are working (some minor changes required in the time-series function, I need to get rid of the characters the unit spits out, and only save the numbers in my text-file).

For the time-being, I plan to apply a step to the controller and use the time-series data to manually tune the PID parameters using MATLAB. I am working on a bunch of shell scripts to automate the entire procedure.

9091   Fri Aug 30 11:00:46 2013 ManasaUpdateGeneralSeries of earthquakes

There has been a series of earthquakes since the big 7.0 in Alaska this morning.

None of the watchdogs were tripped when I came in. But I could not retrieve any info about the suspensions from fast channels because c1sus was not talking to the fb and that required an mxstream restart to fix it.

MC is trying to lock itself, but the seismic doesn't seem to get quiet. So MC is not all that happy.

3459   Mon Aug 23 21:04:14 2010 JenneUpdateTreasureSeriously?

16907   Fri Jun 10 15:02:04 2022 yutaUpdateSUSServo gain sign flipped for MC1 WFS relief

The servo gain for MC1 in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/reliefWFS was flipped to account for COIL_GAIN flip done in 40m/16898.
The reliefWFS script now works fine.

ezcaservo -r 'C1:SUS-MC2_ASCPIT_OUT16' -g ${g} -t${ts} C1:SUS-MC2_PIT_COMM &
ezcaservo -r 'C1:SUS-MC2_ASCYAW_OUT16' -g ${g} -t${ts} C1:SUS-MC2_YAW_COMM &
ezcaservo -r 'C1:SUS-MC1_ASCPIT_OUT16' -g -${g} -t${ts} C1:SUS-MC1_PIT_COMM &
ezcaservo -r 'C1:SUS-MC1_ASCYAW_OUT16' -g -${g} -t${ts} C1:SUS-MC1_YAW_COMM &
ezcaservo -r 'C1:SUS-MC3_ASCPIT_OUT16' -g ${g} -t${ts} C1:SUS-MC3_PIT_COMM &
ezcaservo -r 'C1:SUS-MC3_ASCYAW_OUT16' -g ${g} -t${ts} C1:SUS-MC3_YAW_COMM &

Attachment 1: Screenshot_2022-06-10_15-04-46.png
9919   Tue May 6 19:38:13 2014 JenneUpdateLSCSet up for PRFPMI CM locking

To get ready for the PRFPMI CM trials tonight, I put AS55's cables back to their nominal state, and now have REFL11 I going to IN1 of the CM board.  The OUT1 of the CM board goes to the REFL11I whitening channel.

REFLDC was not disconnected in the last few days, so it is still set up for IN2 of the CM board, with an external offset adjust.

15845   Thu Feb 25 20:37:49 2021 gautamUpdateGeneralSetting modulation frequency and checking IMC offset

The Marconi frequency was tuned by looking at

1. The ~3.68 MHz (= 3*f1 - fIMC) peak at the IMC servo error point, TP1A, and
2. The ~25.8 MHz (= 5*f1 - fIMC) peak at the MC REFL PD monitor port. The IMC error point is not a good place to look for this signal because of the post-demodulation low pass filter (indeed, I didn't see any peak above the analyzer noise floor).

The nominal frequency was 11.066209 MHz, and I found that both peaks were simultaneously minimized by adjusting it to 11.066195 MHz, see Attachment #1. This corresponds to a length change of ~20 microns, which I think is totally reasonable. I guess the peaks can't be nulled completely because of imbalance in the positive and negative sidebands.

Then, I checked for possible offsets at the IMC error point, by injecting a singal to the AO input of the IMC servo board (using the Siglent func gen), at ~300 Hz. I then looked at the peak height at the modulation frequency, and the second harmonic. The former should be minimized when the cavity is exactly on resonance, while the latter is proportional to the modulation depth at the audio frequency. I found that I had to tweak the MC offset voltage slider from the nominal value of 0V to 0.12 V to null the former peak, see Attachment #2. After accounting for the internal voltage division factor of 40, and using my calibration of the IMC error point as 13 kHz/V, this corresponds to a 40 Hz (~50 microns) offset from the true resonant point. Considering the cavity linewidth of ~4 kHz, I think this is a small detuning, and probably changes from lock to lock, or with time of day, temperature etc.

Conclusion: I think neither of these tests suggest that the IMC is to blame for the weirdness in the PRMI sensing, so the mystery continues.

Attachment 1: modFreq.pdf
Attachment 2: IMC_offset.pdf
4128   Sun Jan 9 15:50:55 2011 ranaHowToPSLSetting the PMC gain

I ramped the PMC gain slider to find where it oscillates. It starts going bad at ~13 dB, so the new default gain is 7 dB to give us some margin for alignment improvements, etc.

I also fixed the TIME field in our MEDM screens by adding the following text to the C1IFO_STATE.db file which runs on c1iscaux:
grecord(stringin, "C0:TIM-PACIFIC_STRING") {     field(DESC, "Current time and date")     field(DTYP, "EPICS IOC VAR")     field(SCAN, "1 second")     field(INP, "C1:FEC-34_TIME_STRING") } grecord(stringin, "C0:IFO-TIME_PACIFIC") {     field(DESC, "Current time and date")     field(DTYP, "EPICS IOC VAR")     field(SCAN, "1 second")     field(INP, "C1:FEC-34_TIME_STRING") }
This gets the time info from the c1ioo processor via channel access and gives it these mroe reasonable names. The first record is for backwards compatibility. The second record is a better name and we should use it in the future for all new screens. I had to reboot c1iscaux several times to figure out the right syntax, but its OK now. You have to reopen stale screens to get the field to refresh.

This avoids the previous idea of changing all of the MEDM screens.

7320   Thu Aug 30 18:01:05 2012 ElliUpdateIOOSetting up Input MC cavity scan measurement

Riju, Elli

Today tried to take our first cavity scan.  We unplugged the 55MHz sideband input from the RF combiner on the PSL table, and connected a network analyser instead.  Using the network analyzer we injected a 12dBm signal (swept from 32MHz to 45MHz) through the RF combiner into the EOM to create our swept sidebands.  We measured the  MC cavity response by looking at the signal comming out of the RF photodiode on the MC2 table.  I replaced the BNC cable connected to the RF PD with a longer BNC cable that could reach our network analyzer next to the PSL table.  Riju will post a diagram of our setup.

We didn't see the expected carrier resonances when we performed a cavity scan.  The light incident on the RF PD is around 0.7micro Watts and we are still thinking about whether this is strong enough to see our signal above the noise.  We also want to work out what the strength of our swept sidebands is.  We will attempt to do a 'real' cavity scan tomorrow.

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. 17148 Tue Sep 20 23:06:23 2022 TegaUpdateComputersSetup the 6 new front-ends to boot off the FB1 clone [Tega, Radhika, JC] We wired the front-ends for power, DAQ and martian network connections. Then moved the I/O chassis from the buttom of the rack to the middle just above the KVM switch so we can leave the top og the I/O chassis open for access to the ports of OSS target adapter card for testing the extension fiber cables. Attachment 1 (top -> bottom) c1sus2 c1iscey c1iscex c1ioo c1sus c1lsc When I turned on the test stand with the new front-ends, after a few minutes, the power to 1x7 was cut off due to overloading I assume. This brought down nodus, chiara and FB1. After Paco reset the tripped switch, everything came back without us actually doing anything, which is an interesting observation. After this event, I moved the test stand power plug to the side wall rail socket. This seems fine so far. I then brought chiara (clone) and FB1 (clone) online. Here are some changes I made to get things going: ## Chiara (clone) • Edited '/etc/dhcp/dhcpd.conf' to update the MAC address of the front-ends to match the new machines, then run • sudo service isc-dhcp-server restart • then restart front-ends • Edited '/etc/hosts' on chiara to include c1iscex and c1iscey as these were missing ## FB1 (clone) Getting the new front-ends booting off FB1 clone: 1. I found that the KVM screen was flooded with setup info about the dolphin cards on the LLO machines. This actually prevented login using the KVM switch for two of these machines. Strangely, one of them 'c1sus' seemed to be fine, see attachment 2, so I guessed this was bcos the dolphin network was already configured earlier when we were testing the dolphin communications. So I decided to configure the remaining dolphin cards. To do so, we do the following Dolphin Configuration: 1a. Ideally running sudo /opt/DIS/sbin/dis_mkconf -fabrics 1 -sclw 8 -stt 1 -nodes c1lsc c1sus c1ioo c1iscex c1iscey c1sus2 -nosessions should set up all the nodes, but this did not happen. In fact, I could no longer use the '/opt/DIS/sbin/dis_admin' GUI after running this operation and restarting the 'dis_networkmgr.service' via sudo systemctl restart dis_networkmgr.service so I logged into each front-end and configured the dolphin adapter there using sudo /opt/DIS/sbin/dis_config After which I shut down FB1 (clone) bcos restarting it earlier didn't work, I waited a few minutes and then started it. Everything was fine afterward, although I am not quite sure what solved the issue as I tried a few things and I was glad to see the problem go! 1b. I later found after configuring all the dolphin nodes that 2 of them failed the '/opt/DIS/sbin/dis_diag' test with an error message suggesting three possible issues of which one was 'faulty cable'. I looked at the units in question and found that swapping both cables with the remaining spares solved the problem. So it seems like these cables are faulty (need to double-check this). Attachment 3 shows the current state of the dolphin nodes on the front-ends and the dolphin switch. 2. I noticed that the NFS mount service for the mount points '/opt/rtcds' and '/opt/rtapps' in /etc/fstab exited with an error, so I ran sudo mount -a 3. edit '/etc/hosts' to include c1iscex and c1iscey as these were missing ## Front-ends To test the PCIe extension fiber cables that connect the front-ends to their respective I/O chassis, we run the following command (after booting the machine with the cable connected): controls@c1lsc:~$ lspci -vn | grep 10b5:3
Subsystem: 10b5:3120
Subsystem: 10b5:3101

If we see the output above, then both the cable and OSS card are fine (We know from previous tests that the OSS card on the I/O chassis is good). Since we only have one I/O chassis, we repeat the step above 8 times, also cycling through the six new front-end as we go so that we are also testing the installed OSS host adapter cards. I was able to test 4 cables and 4 OSS host cards (c1lsc, c1sus, c1ioo, c1sus2), but the remaining results were inconclusive (i.e. it seems to suggest that 3 out of the remaining 5 fiber cables are faulty, which in itself would be considered unfortunate but I found the reliability if the test to be in question when I went back to test the functionality to the 2 remaining OSS host cards using a cable that passed the test earlier and it didn't pass. After a few retries, I decided to call it a day b4 I lose my mind) and need to be redone again tomorrow.

Note: We were unable to lay the cables today bcos these tests were not complete, so we are a bit behind the plan. Would see if we can catch up tomorrow.

Quote:

## Plan for the remainder of the week

Tuesday

• Setup the 6 new front-ends to boot off the FB1 clone.
• Test PCIe I/O cables by connecting them btw the front-ends and teststand I/O chassis one at a time to ensure they work
• Then lay the fiber cables to the various I/O chassis.

Attachment 1: IMG_20220921_084220465.jpg
Attachment 2: dolphin_err_init_state.png
Attachment 3: dolphin_final_state.png
17151   Wed Sep 21 17:16:14 2022 TegaUpdateComputersSetup the 6 new front-ends to boot off the FB1 clone

[Tega, JC]

We laid 4 out of 6 fiber cables today. The remaining 2 cables are for the I/O chassis on the vertex so we would test the cables the lay it tomorrow. We were also able to identify the problems with the 2 supposedly faulty cable, which are not faulty. One of them had a small bend in the connector that I was able to straighten out with a small plier and the other was a loose connection in the switch part. So there was no faulty cable, which is great! Chris wrote a matlab script that does the migration of all the model files. I am going through them, i.e. looking at the CDS parameter block to check that all is well. Next task is to build and install the updated models. Also need to update the '/opt/rtcds' and '/opt/rtapps' directory to the latest in the 40m chiara system.

17164   Thu Sep 29 15:12:02 2022 JCUpdateComputersSetup the 6 new front-ends to boot off the FB1 clone

[Jamie, Christopher, JC]

This morning we decided to label the the fiber optic cables. While doing this, we noticed that the ends had different label, 'Host' and 'Target'. Come to find out, the fiber optic cables are directional. Four out of Six of the cables were reversed. Luckily, 1 cable for the 1Y3 IO Chassis has a spare already laid (The cable we are currently using).  Chris, Jamie, and I have begun reversing these cable to there correct position.

 Quote: [Tega, JC] We laid 4 out of 6 fiber cables today. The remaining 2 cables are for the I/O chassis on the vertex so we would test the cables the lay it tomorrow. We were also able to identify the problems with the 2 supposedly faulty cable, which are not faulty. One of them had a small bend in the connector that I was able to straighten out with a small plier and the other was a loose connection in the switch part. So there was no faulty cable, which is great! Chris wrote a matlab script that does the migration of all the model files. I am going through them, i.e. looking at the CDS parameter block to check that all is well. Next task is to build and install the updated models. Also need to update the '/opt/rtcds' and '/opt/rtapps' directory to the latest in the 40m chiara system.

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
ELOG V3.1.3-