The microscope shipped back to the vendor for credit yesterday.
http://www.amscope.com/3-5x-180x-boom-stand-trinocular-zoom-stereo-microscope-with-144-led-ring-light-and-10mp-camera.html will be ordered today.
The actual unit we are getting has lockable zoom for better repeatability after calibration: SM-3NTPZZ-144
16 years old Lightwave NPRO M126-1064-700, sn 415 power output is tripping continously to zero.
The Lightwave Controller 125/126-OPN-POS sn516 was used in this test. Settings were lowered to close to nominal values without any success.
One can not determine what is broken: head or controller. This NPRO head was under Manasa's desk.
Property tag found.
As per Steve's request, I've checked the alignment of the IMC and the arms. These three cavities are locked and aligned.
I removed the video monitoring can and replaced it with Olympus SP-570UZ camera. It has no IR blocker. The OSEM light are dominant because I can not zoom in more.
I left the camera in place so you can try it. Leave the LEXAN plate on the glass window so no accident can happen. The illuminator is on and you can turn it off-on with the manual switch, close to the camera. Camera manual is on my desk.
The attached is the ETMY image with the single arm locked. This was the best I could do. Here is the recipe
Your technique works Koji
We spent some time trying to get the noise-budgeting code running today. I guess eventually we want this to be usable on the workstations so we cloned the git repo into /ligo/svncommon. The main objective was to see if we had all the dependencies for getting this code running already installed. The way Evan has set the code up is with a bunch of dictionaries for each of the noise curves we are interested in - so we just commented out everything that required real IFO data. We also commented out all the gwpy stuff, since (if I remember right) we want to be using nds2 to get the data.
Running the code with just the gwinc curves produces the plots it is supposed to, so it looks like we have all the dependencies required. It now remains to integrate actual IFO data, I will try and set up the infrastructure for this using the archived frame data from the 2016 DRFPMI locks..
I looked through the lab area to do a fast photodiode inventory check, as we may need to buy some for the higher order mode spectroscopy SURF project. I looked on the following optical tables: ETMY, ITMY, BS, AS, PSL, SP, ITMX, Jenne laser table, and ETMX, as well as the photodiode cabinet, and could only find two 1611s. Here is a summary of the inventory:
I have not yet checked if these photodiodes are in working order.
Dataviewer wouldn't launch on pianosa - it seemed to work fine on Donatella though. Rana suggested using the ipcs -q command. The complete fix can be found in this elog. This did the trick, dataviewer runs fine on Pianosa now...
Since we'd like to get back to DRSE locking, I tried locking the DRMI tonight. I did the following:
GV 26 April 2017, 3pm: Forgot to note yesterday that I re-connected the suspect Satellite box, which has been connected to the SRM signal chain, back to the SRM suspension. I did not see any instances of glitching during my work last night. Also added pictures showing shifted spots on ITMs when PRC is locked relative to when arms are locked...
I got a couple of ~30min long DRMI lock stretches today. The settings I used are essentially the same as what I had back in November. Though we have since made some changes to the IMC RF signal chain, I guess it is not unreasonable that the LSC Demod phases that worked then work now as well.
In the lock stretches, I did the following:
On the side, I'm also looking at whether the PRC angular feedforward filters, last trained in October 2016, remain valid. Even post midnight, I am unable to lock the DRMI without turning on the FF, and looking at the POP QPD PIT and YAW signal spectra with the FF on vs FF off, there is definitely some improvement in the 1-4Hz band (plot to follow), question is whether we can do better and hence improve the DRMI duty cycle/ make the lock acquisition easier. To this end, I centered the beam on the POP QPD after locking and dither aligning the PRC on carrier, and have taken some data to look at.
So, much data analysis to follow - the idea is to put together a DRMI noise budget with Evan's NB code. For now, here are the uncalibrated control signal spectra.
one of these signals does not look like the others: explanation?
I took a closer look at the POP QPD/ PRC angular feedforward situation yesterday. I thought it would be useful to have a POP QPD MEDM screen. Looking at the PIT and YAW channel filter modules, the anti-whitening filters seemed different from what we have for other channels that are connected to the Pentek interface board (e.g. MCL). So I copied over the 150:15 (z:p) filter, and also turned on a 60Hz comb. The LSC offsets script does not set the dark offsets for this QPD, so I manually put in the dark offsets for the PIT, YAW and SUM channels as well. For the locking, I first locked the arms on IR an dither aligned them. Then I locked the PRMI on carrier, ran the PRC dither alignment, and went over to the ITMX pickoff table and centered the beam on the QPD by making the PIT and YAW channel timeseries oscillate around approximately zero.
After these tweaks, I collected ~40mins of data with the angular FF OFF/ON. I did not DC couple the ITM Oplev servos, but Eric tells me that this did not make a difference to the achievable subtraction in the past. Here is the frequency domain multicoherence analysis - I used the BS_X and BS_Y seismometer channels as witnesses. I've also put a plot with what the raw FF filter coefficients look like (no fitting yet).
Looks like we can do better for both DOFs - it even seems like we are injecting noise with the current FF filters in some bands, perhaps we can do a better job of rolling off the filters outside the band of interest. Eric and I were discussing MATLAB's "reduce" routine for this purpose, I will play around with it and see if I get a better fit.
Unfortunately, I encountered a strange error when trying to pull data with nds2 today, it kept complaining RuntimeError: Too many channels or too much data requested. even though I have pulled longer stretches of data for more channels with 16k sampling rate as recently as last week. Shorter duration requests (<600 seconds) seemed to work fine though... So I had to use cds.getdata to pull the data, and they're much too large to attach. Has anyone else encountered a similar error?
The mystery of the spots on the ITMs when the PRC is locked on carrier remains - after talking this over with Koji, we figured that even with the carrier resonant, the spot will be much dimmer than the spots when the arms are locked, but what I see on the cameras is still a pretty beefy spot. The real cavity mode is actually visible where it should be (I marked the locations of the spots with arms well-aligned with a marker on the monitors), as given away by some twinkling that is visible only when the cavity is locked. But what ghost beam is so intense it looks almost as bright as when the arm is locked?
GV 10pm 28 April 2017: Turns out this is the spot from the single bounce off the ETM transmitting back through the ITM and hitting the suspension cage (hence the bright spot). Johannes and I confirmed by moving the ETM, the spot moved with it. I just never paid attention to this spot before.
For the traces I posted, I had not turned on the whitening for the SRCL sensing PD (REFL55). However, I took a spectrum on a subsequent lock, with the analog whitening + digital dewhitening turned on for all 3 PDs (AS55, REFL11 and REFL55), and the HF part of the SRCL spectrum still looked anomalous. I'm putting together the detailed NB, but here's a comparison between the signals from the 3 RFPDs with the PSL shutter closed (but whitening engaged, and with the analog gains at the same values as used during the locking).
To convert the y-axis into m/rtHz, I used data from a sensing matrix measurement I took yesterday night during a DRMI lock - I turned on lines between 300 Hz and 325 Hz for the 3DOFs for ~5 minutes, downloaded the RFPD error signal data and did the demodulation. I used numbers from this elog to convert the actuator drive from cts to m. The final numbers I used were:
MICH (AS55_Q): 8.706 * 10^11 cts/m
PRCL (REFL11_I): 2.757 * 10^12 cts/m
SRCL (REFL55_I): 1.995 * 10^10 cts/m
So it looks like there may be something weird going on with the REFL55 signal chain. Looking at the LSC rack (and also suggested by an elog search), it looks like the demodulation is done by a demod board labelled "POP55" - moreover, the demodulated outputs are taken not from the regular output ports on this board, but from the "MON" ports on the front panel.
I forgot we had done this last year already, but we updated the control room network switch labels and double checked all the connections. Here is the status of the connections and labels as of today:
There are a few minor changes w.r.t. labeling and port numbers compared to the Dec 2015 entry. But it looks like there was no IP clash between Rossa and anything (which was one of the motivations behind embarking on this cleanup). We confirmed by detatching the cable at the PC end of Rossa, and noticed the break in the ping signals. Plugging the cable back in returned the pings. Because Rossa is currently un-bootable, I couldn't check the MAC address.
We also confirmed all of this by using the web browser interface for the switch (IP = 192.168.113.249).
One is broken, two are ready to steer green and 3 available in un known condition
I also have a functional one on my desk, which has one of the wires repaired.
I've been playing around with Evan's NB code trying to put together a noise budget for the data collected during the DRMI locks last week. Here is what I have so far.
Attachment #1: Sensing matrix measurement.
Attachment #2: MICH OLTF measurement vs model
Attachment #3: Noise budget
I think I did the various conversions/calibrations/loop algebra correctly, but I may have overlooked something. Now that the framework for doing this is somewhat set up, I will try and put together analogous NBs for PRCL and SRCL.
GV 22 August 2017: Attachment #4 is the summary of my demod board efficiency investigations, useful for converting sensing measurement numbers from cts/m to W/m.
I think the most important next two items to budget are the optical lever noise, and the coil driver noise. The coil driver noise is dominated at the moment by the DAC noise since we're operating with the dewhitening filters turned off.
In order to do so, I took a swept sine measurement with a few points between 50 Hz and 500 Hz. The transfer function between C1:LSC-MICH_OUT_DQ and the Oplev Servo Output point (e.g. C1:SUS-BS_OL_PIT_OUT etc) was measured. I played around with the excitation amplitude till I got coherence > 0.9 for the TF measurement, while making sure I wasn't driving the Oplev error point too hard that side-lobes began to show up in the MICH control signal spectrum.
I was also looking at the Oplev servo shapes and noticed that they are different for the ITMs and the BS (Attachment #1). Specifically, for the ITM Oplevs, an "ELP15" is used to do the roll-off while an "ELP35" is employed in the BS servo (though an ELP35 also exists in the ITM Oplev filter banks). I got lost in an elog search for when these were tuned, but I guess the principles outlined in this elog still hold and can serve as a guideline for Oplev loop tweaking.
Coil driver noise estimation to follow
GV 10 May 12:30pm: I've uploaded another copy of the NB (Attachment #3) with the contributions from the ITMs and BS separated. Looks like below 100Hz, the BS coupling dominates, while the hump/plateau around 350Hz is coming from ITMX.
That's a good find.
I first shutdown the SRM watchdog, noted cabling between these boards and also the AI board as well as output to Sat. Box. I also needed to shutdown the MC2 watchdog as I had to remove the DAC output to MC2 in order to remove the SRM Dewhitening board from the rack. This connection has been restored, MC locks fine now.
I believe the ETMs and ITMs are different from the others.
I've added marked-up schematics + high-res photographs of the SRM coil driver board and dewhitening board to the 40m DCC Document tree (D1700217 and D1700218).
In the attached marked-up schematics, I've also added the proposed changes which Rana and I discussed earlier today. For the thick-film -> thin-film resistor switching, I will try and make a quick LISO model to see if we can get away with replacing just a few rather than re-stuff the whole board.
Another change I think should be made, but I forgot to include on the markups: On the dewhitening board, we should probably replace the decoupling capacitors C41 and C52 with equivalent value electrolytic caps (they are currently tantalum caps which I think are susceptible to fail by shorting input to output).
I've made the LISO models for the dewhitening board and coil driver boards I pulled out.
Attached is a plot of the current noise in the current configuration (i.e. dewhitening board just has a gain x3 stage, and then propagated through the coil driver path), with the top 3 noise contributions: The op-amps (op3 and op5) are the LT1125s on the coil driver board in the bias path, while "R12" is the Johnson noise from the 1k input resistace to the OP27 in the signal path.
Assuming the OSEMs have an actuation gain of 0.016 N/A (so 0.064 N/A for 4 OSEMs), the current noise of ~1e-10 A/rtHz translates to a displacement noise of ~3e-15m/rtHz at ~100Hz (assuming a mirror mass of 0.25kg).
I have NOT included the noise from the LM6321 current buffers as I couldn't find anything about their noise characteristics in the datasheet. LISO files used to generate this plot are attached.
I first set the bias sliders to 0 on the MEDM screen (after checking that the nominal values were stored), then shut down the watchdogs, and then pulled out the boards for inspection + photo-taking.
I've uploaded high-res photos + marked up schematics to the same DCC page linked in the previous page. I've noted the S/Ns of the ITM, BS and SRM boards on the page, I think it makes sense to collect everything on one page, and I guess eventually we will unify everything to a one or two versions.
To take the photos, I tried to reproduce the "LED light painting" technique reported here. I mounted the Canon EOS Rebel T3i on a tripod, and used some A3 sheets of paper to make a white background against which the board to be photographed was placed. I also used the new Macro lens we recently got. I then played around with the aperture and exposure time till I got what I judged to be good photos. The room lights were turned off, and I used the LED on my phone to do the "painting", from ~a metre away. I think the photos have turned out pretty well, the component values are readable.
I got some hands-on-experience on using RF photodetectors and the Network Analyzer from Koji. There were newly purchased RF photodetectors from Electro-Optics Technology, Inc.. These were InGaAs Photodetectors with model no.: 120-10050-0001(ET-3010) and 120-10056-0001(ET-3040). The User Guide for the two detectors can be found here. This is the first time we bought the ET-3010 model PD for the 40m lab. It has an operation bandwith >1.5GHz(not tested yet), much higher than other PDs of its kind. This can be used for detecting the output as we 'sweep' the laser frequency for getting data on the optical cavities and the resonating modes inside the cavity. We just tested out the ET-3040 model today but will test out the ET-3010 next week.
Tools and Machines Used:
We worked on the optical bench right in front of the main entrance to the lab. We put the cables, power chords, etc. to their respective places. We used screws, poles, T's, I's, multimeter, Network/Spectrum Analyzer(along with the moving table), a lab computer, Oscilloscope, power supply and the aforementioned PDs for our testing. We took these items from the stack of tools at the Y-arm and the boxes of various different labelled palced near the X-arm. We moved the Network Analyzer(along with the bench) from near the Y-arm to our workplace.
I will include a rough schematic of the setup later.
We alligned the reference PD(High Speed Photoreceiver model 1611) and the test PD(ET-3040 in this case) to get optimal power output. We had set the pump current for the laser at 19.5mA which produced a power of 1.00mW at the output of the fiber couple. At the reference detector the measured voltage was about 1.8V and at the DUT it was about 15mV. The DC transimpedance for the reference detector is 10kOhm and its responsivity to 1064 nm is around 0.75A/W. Using this we calculate the power at the reference detector to be 0.24mW. The DC transimpedance for the DUT is 50Ohm and the responsivity of about 0.9A/W. This amounts to a power of about 0.33mW. After measuring the DC voltages, we connected the laser input to the Network Analyzer and gave in an RF signal with -10dBm and frequency modulation from 100 kHz to 500 MHz. The RF output from the Analyzer is coupled to the Reference Channel(CHR) of the analyzer via a 20dB directional coupler. The AC output of the reference detector is given at Channel A(CHA) and the output from the DUT is given to Channel B(CHB). We got plots of the ratios between the reference detector, DUT and the coupled refernce for the Transfer Function and the Phase. We found that the cut-off frequency for the ET3040 model was at arounf 55 MHz(stated as >50MHz in the data sheet). We have stored the data using the lab PC in the directory .../scripts/general/netgpibdata/data.
The bandwidth of the ET-3040 PD is as stated in the data sheet, >50 MHz.
These PDs have an internal power supply of 3V for ET-3040 and 6V for ET-3010. Do not leave these connected to any instruments after the experiments have been performed or else the batteries will get drained if there is any photocurrent on the PDs.
A similar procedure has to be followed in order to test the ET-3010 PD. I will be doing this tentatively on Monday.
I've spent the last week investigating various parts of the DAC -> OSEM coil signal chain in order to add these noises to the MICH NB. Here is what I have thus far.
I am adding the text files with the data readings and paramater settings along with the Bode Plot of the data. I plotted these graphs using matplotlib module with python 2.7.
I got some hands-on-experience on using RF photodetectors and the Network Analyzer from Koji. There were newly purchased RF photodetectors from Electro-Optics Technology, Inc.. These were InGaAs Photodetectors with model no.: 120-10050-0001(ET-3010) and 120-10056-0001(ET-3040). The User Guide for the two detectors can be found here. This is the first time we bought the ET-3010 model PD for the 40m lab. It has an operation bandwith >1.5GHz(not tested yet), much higher than other PDs of its kind. This can be used for detecting the output as we 'sweep' the laser frequency for getting data on the optical cavities and the resonating modes inside the cavity. We just tested out the ET-3040 model today but will test out the ET-3010 next week...
In continuation with the previous(ET-3040 PD) test.
The ET-3010 PD requires to be fiber coupled for optimal use. I will try to test this model without the fiber couple tomorrow and see whether it works or not.
I wanted to match a noise model to noise measurement for the coil-driver de-whitening boards. The main objectives were:
In continuation to the previous test conducted on the ET-3040 PD, I performed a similar test on the ET-3010 model. This model requires a fiber couple input for proper testing, but I tested it in free space without a fiber couple as the laser power was only 1.00 mW and there was not much danger of scattering of the laser beam. The Data Sheet can be found here
The schematic(attached below) and the procedure are the same as the previous time. The pump current was set to 19.5 mA giving us a laser beam of power 1.00mW at the fiber couple output. The measured voltage for the reference detector was 1.8V. For the DUT, the voltage is amplified using a low noise amplifier(model SR-560) with a gain of 100. Without any laser incidence on the DUT, the multimeter reads 120.6 mV. After alligning the laser with the DUT, the multimeter reads 348.5 mV, i.e. the voltage for the DUT is 227.9/100 ~ 2.28 mV. The DC transimpedance of the reference detector is 10kOhm and its responsivity to 1064 nm is around 0.75 A/W. Using this we calculate the power at the reference detector to be 0.24 mW. The DC transimpedance for the DUT is 50Ohm and the responsivity is around 0.85 A/W. Using this we calculate the power at the DUT to be 0.054 mW. After this we connect the the laser input to the Netwrok Analyzer(AG4395A) and give an RF signal with -10dBm and frequency modulation from 100 kHz to 500 MHz.The RF output from the Analyzer is coupled to the Reference Channel(CHR) of the analyzer via a 20dB directional coupler. The AC output of the reference detector is given at Channel A(CHA) and the output from the DUT is given to Channel B(CHB). We got plots of the ratios between the reference detector, DUT and the coupled refernce for the Transfer Function and the Phase. I stored the data under the directory.../scripts/general/netgpibdata/data. The Bode Plot has been attached below and seeing it we observe that the cut-off frequency for the ET-3010 model is atleast over 500 MHz(stated as >1.5 GHz in the data sheet).
The bandwidth of the ET-3010 PD is atleast 500MHz, stated in the data sheet as >1.5GHz.
The ET-3010 PD has an internal power supply of 6V. Don't leave the PD connected to any instrument after the experimentation is done or else the batteries will get drained if there is any photocurrent on the PDs.
Caliberate the vertical axis in the Bode Plot with transimpedance(Ohms) for the two PDs. Automate the procedure by making a Python script for taking multiple set of readings from the Netwrok Analyzer and aslo plot the error bands.
This measurement has been troublesome - I was plagued by large 60Hz harmonics (see Attachment #1), the cause of which was unknown. I powered all electronics used in the measurement set up from the same power strip (one of the new surge-protecting ones Steve recently acquired for us), but these remained present. Yesterday, Koji helped me troubleshoot this issue. We did the various things, I try to put them here in the order we did them:
Today, I tried to repeat the measurement, with the newly made twisted ribbon cable, but the large 60Hz harmonics were back. Then I realized we had also disconnected the WiFi extender and GPIB box yesterday.
Turns out that connecting the Prologix box to the SR785 (even with no power) is the culprit! Disconnecting the Prologix box makes these harmonics go away. I was using the box labelled "Santuzza.martian" (192.168.113.109), but I double-checked with the box labelled "vanna.martian" (192.168.113.105, also a different DC power supply adapter for the box), the effect is the same. I checked various combinations like
but it looks like connecting the GPIB box to the analyzer is what causes the problem. This was reproducible on both SR785s in the lab. So to make this measurement, I had to do things the painful way - acquire the spectrum by manually pushing buttons with the GPIB box disconnected, then re-connect the box and download the data using SRmeasure --getdata. I don't fully understand what is going on, especially since if the input connector is directly terminated using a 50ohm BNC terminator, there are no harmonics, regardless of whether the GPIB box is connected or not. But it is worth keeping this problem in mind for future low-noise measurements. My elog searches did not reveal past reports of similar problems, has anyone seen something like this before?
It also looks like my previous measurement of the de-whitening board noises was plagued by the same problem (I took all those spectra with the GPIB boxes connected). I will repeat this measurement.
At the meeting this week, it was decided that
I also think it would be a good idea to up the 100-ohm resistors in the bias path on the ITM coil driver boards to 1kohm wire-wound. Since the dominant noise on the coil-driver boards is from the voltage noise of the Op-Amps in the bias path, this would definitely be an improvement. Looking at the current values of the bias MEDM sliders, a 10x increase in the resistance for ITMX will not be possible (the yaw bias is ~-1.5V), but perhaps we can go for a 4x increase?
The plan is to then re-install the boards, and see if we can
We can then take a call on how much to up the series resistance in the DAC signal path.
Now that I have figured out the cause of the harmonics, I will also try and measure the combined electronics noise of de-whitening board + coil driver board and compare it to the model.
Using Alberto's paper LIGO-T10002-09-R titled "40m RF PDs Upgrade", I calibrated the vertical axis in the bode plots I had obtained for the two PDs ET-3010 and ET-3040.
I am not sure whether the values I have obtained are correct or not(i.e. whether the calibration is correct or not). Kindly review them.
EDIT: Attached the formula used to calculate transimpedance for each data point and the values of other paramaters.
EDIT 2: Updated the plots by changing the conversion for gettin ghte ratio of the transfer functions from 10^(y/10) to 10^(y/20).
I've given Steve a list of the thin-film resistors we need to implement the changes discussed in the preceeding elogs - but I figured it would be good to see if we can realize the projected improvement in MICH displacement noise just by fixing the BS Oplev loop shape and turning the existing whitening on. Before re-installing them however, I did make a few changes:
Photos of all the boards were taken prior to re-installation, and have been uploaded to the 40m Google Photos page - I will update schematics + photos on the DCC page once other planned changes are implemented.
I also measured the transfer functions on the de-whitened signal paths on all the boards before re-installing them. I then fit everything using LISO, and updated the filter banks in Foton to match these measurements - the original filters were copied over from FM9 and FM10 to FM7 and FM8. The new filters are appended with the suffix "_0517", and live in FM9 and FM10 of the coil output filter banks. The measured TFs (for ITMs and BS) are summarized in Attachment #1, while Attachment #2 contains the data and LISO file used to do the fits (path to the .bod files in the .fil file will have to be changed appropriately). I used 2 complex pole pairs at ~10 Hz, two complex zero pairs at ~100Hz, real poles at ~15Hz and ~3kHz, and real zeros at ~100Hz and ~550Hz for the fits. The fits line up well with the measured data, and are close enough to the "expected" values (as calculated from component values) to be explained by tolerances on the installed components - I omit the plots here.
After re-installing the boards in the Eurocrate, restoring rough alignment, and updating the filter banks with the most recent measured values, I wanted to see if I could turn the whitening on for one of the optics (ITMY) smoothly before trying to do so in the full DRMI - switching off the "SimDW_0517" filter (FM9) should switch the signal path on the de-whitening board from bypass to de-whitened, and I had confirmed last week with an extender board that the voltage at the appropriate backplane connector pin does change as expected when the FM9 MEDM button is toggled (for both ITMs, BS and SRM). But today I was not able to engage this transition smoothly, the optic seems to be getting kicked around when I engage the whitening. I will need to investigate this further.
Unrelated to this work: the ETMY Oplev HeNe is dead (see Attachment #3). I thought we had just replaced this laser a couple of months ago - what is the expected lifetime of these? Perhaps the power supply at the Y-end is wonky and somehow damaging the HeNe heads?
I think the reason I am unable to engage the de-whitening is that the OL loop is injecting a ton of control noise - see Attachment #1. With the OL loop off (i.e. just local damping loops engaged for the ITMs), the RMS control signal at 100Hz is ~6 orders of magnitude (!) lower than with the OL loop on. So turning on the whitening was just railing the DAC I guess (since the whitening has something like 60dB gain at 100Hz).
The Oplev loops for the ITMs use an "Ellip15" low-pass filter to do the roll-off (2nd order Elliptic low pass filter with 15dB stopband atten and 2dB ripple). I confirmed that if I disable the OL loops, I was able to turn on the whitening for ITMY smoothly.
Now that the ETMY OL HeNe has been replaced, I restored alignment of the IFO. Both arms lock fine (I was also able to engage the ITMY Coil Driver whitening smoothly with the arm locked). However, something funny is going on with ASS - running the dither seems to inject huge offsets into the ITMY pit and yaw such that it almost immediately breaks the lock. This probably has to do with some EPICS values not being reset correctly since the recent slow-machine restarts (for instance, the c1iscaux restart caused all the LSC RFPD whitening gains to be reset to random values, I had to burt-restore the POX11 and POY11 values before I could get the arms to lock), I will have to investigate further.
GV edit 2pm 31 May: After talking to Koji at the meeting, I realized I did not specify what channel the attached spectra are for - it is C1:SUS-ITMY_ULCOIL_OUT.
But today I was not able to engage this transition smoothly, the optic seems to be getting kicked around when I engage the whitening. I will need to investigate this further.
We tried to debug the mysterious sudden failure of ASS - here is a summary of what we did tonight. These are just notes for now, so I don't forget tomorrow.
What are the problems/symptoms?
What are the (known) changes since the servos were last working?
Hypotheses plus checks (indented bullets) to test them:
For whatever reasons, it appears that dithering the cavity mirrors at frequencies with amplitudes that worked ~3 weeks ago is no longer giving us the correct error signals for dither alignment. We are out of ideas for tonight, TBC tomorrow...
Looks like there was a power glitch at around 10am today.
All frontends, FB, Megatron, Optimus were offline. Chiara reports an uptime of 666 days so looks like its UPS works fine. PSL was tripped, probably the end lasers too (yet to check). Slow machines seem alright (Responds to ping, and I can also telnet into them).
Since all the frontends have to be re-started manually, I am taking this opportunity to investigate some cds issues like the lack of a dmesg log file on some of the frontends. So the IFO will be offline for sometime.
GV Jun 5 6pm: From my discussion with jamie, I gather that the fact that the dmesg output is not written to file is because our front-ends are diskless (this is also why the ring buffer, which is what we are reading from when running "dmesg", gets cleared periodically)
[Koji, Rana, Gautam]
The state this work was started in was as indicated in the previous elog - c1ioo wasn't ssh-able, but was responding to ping. We then did the following:
Why does ntpdate behave this way? And only on one of the frontends? And what is the remaining RFM error?
Koji then restarted the IMC autolocker and FSS slow processes on megatron. The IMC locked almost immediately. The MC2 transmon indicated a large shift in the spot position, and also the PMC transmission is pretty low (while the lab temperature equilibriates after the AC being off during peak daytime heat). So the MC transmission is ~14500 counts, while we are used to more like 16,500 counts nowadays.
Re-alignment of the IFO remains to be done. I also did not restart the end lasers, or set up the Marconi with nominal params.
Attachment #3 - Status of the Master Timing Sequencer after various reboots and power cycling of front ends and associated electronics.
Attachment #4 - Warning lights on C1IOO
Now IFO work like fixing ASS can continue...
I tried all versions of power cycling and debugging this problem known to me, including those suggested in this thread and from a more recent time. I am leaving things as it for the night, will look into this more tomorrow. I've also shutdown the ETMX watchdog for the time being. Looks like this has been down since 24Jun 8am UTC.
I have spent my first few days as a SURF getting experience working with the Network/Spectrum Analyzer (AG 4395A). After an introduction to the 40m by Koji, I was tasked with using the AG4395A to measure the transfer function of several filters (for example, Mini-Circuits Low Pass Filter SLP-30). I am now familiar with configuring the AG 4395A, taking a single set of data using a command from one of the control computers, and plotting the dataset as a Bode plot (separate plots for magnitude and phase) using Python.
To experiment with plotting multiple datasets on a single Bode plot, I used a single dataset from the Network Analyzer using the SLP-30 filter and added random noise to create ten datasets to plot. I am attaching the resulting Bode plot, which has the ten generated sets of data plotted along with their average.
We discussed with Rana and Koji how to interpret this type of dataset from the Network Analyzer. Instead of considering the magnitude and phase as separate quantities, we should consider them together as a single complex number in the form H(f) = M exp(iπP/180), where M is the magnitude and P is the phase in degrees. We can then find the average value of the measured quantity in its complex number form (x + iy), as opposed to just taking the average of the magnitude and phase separately.