40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 203 of 335  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  12248   Wed Jul 6 08:34:00 2016 SteveUpdateVACRGA scan at day 639

The last RGA scan of this pumpdown 78

Pressure plot of 640 days long pd 78

CC1 cold cathode gauge was jump started with an accidental pressure glitch, that you can see on P1 plot

 

Attachment 1: RGAscan639d.png
RGAscan639d.png
Attachment 2: pd78d640.png
pd78d640.png
  9223   Wed Oct 9 11:48:10 2013 SteveUpdateVACRGA scan at day 65

 

 Valve configuration: Vacuum Normal

Attachment 1: scanRGApd76m65d.png
scanRGApd76m65d.png
Attachment 2: pd76m65d.png
pd76m65d.png
  7461   Tue Oct 2 09:13:16 2012 SteveUpdateVACRGA scan at day 7

Quote:

Quote:

 The new cold cathode gauge CC1 is in place. We were at atmosphere for 28 days ......more later

 

 cc1 = 2.3e-5 Torr at day 6 vacuum normal

 

Attachment 1: pd73md7.png
pd73md7.png
  12642   Mon Nov 28 09:45:44 2016 SteveUpdateVACRGA scan at pumpdown day 40

The vacuum envelope ~1 C warmer today than 7 days ago. Bad peaks are coming down as normal.

 

Attachment 1: RGAscan_d40.png
RGAscan_d40.png
Attachment 2: d2_&_d7scan.png
d2_&_d7scan.png
Attachment 3: RGAd2.png
RGAd2.png
  10599   Mon Oct 13 14:44:52 2014 SteveUpdateVACRGA scan pd78 -day 13

 Our first RGA scan since May 27, 2014 elog10585

 The Rga is still warming up. It was turned on 3 days ago as we recovered from the second power outage.

 

Attachment 1: RGAscan13Oct2014.png
RGAscan13Oct2014.png
  10741   Mon Dec 1 17:13:57 2014 SteveUpdateVACRGA scan pd78 -day 63

Quote:

 Our first RGA scan since May 27, 2014 elog10585

 The Rga is still warming up. It was turned on 3 days ago as we recovered from the second power outage.

 

 

Attachment 1: RGAscanD63.png
RGAscanD63.png
  11184   Tue Mar 31 09:03:32 2015 SteveUpdateVACRGA scan pd78 day 182

 

 

Attachment 1: RGApd78d182.png
RGApd78d182.png
  11387   Wed Jul 1 10:01:25 2015 SteveUpdateVACRGA scan pd78 day 275

 

 

Attachment 1: rga275d.png
rga275d.png
  11666   Mon Oct 5 10:11:35 2015 SteveUpdateVACRGA scan pd78 day 386

RGA background scan.

The IFO is closed off from RGA with VM1

CC4 ( and CC1)  is still flaky and it's interlock closes VM1

 

Attachment 1: RGA_background.png
RGA_background.png
  11697   Mon Oct 19 11:20:34 2015 gautamUpdateVACRGA scan reset

Steve pointed out that in the aftermath of the Nitrogen running out a couple of times last week, the RGA had shut itself off thinking that there was a leak and so it was not performing the scheduled scans once a day. So the data files from the scheduled scans were empty in the /opt/rtcds/caltech/c1/scripts/RGA/logs directory. The wiki page for getting it up and running again is up-to-date, but the script RGAset.py did not exist on the c0rga machine, which the RGA is communicating with via serial port. I copied over the script RGAset.py from rossa to c0rga and ran the script on that machine - but the error flags it returned were not all 0 (indicating some error according to the manual) - so I edited the script to send just the initialize command ('IN0') and commented out the other commands, after which I got error flags which were all 0. After this, I ran a manual scan using 'RGAlogger.py', and it appears that the RGA is now able to take scans again - I'm attaching a plot of the scan results. We've saved this scan as a reference to compare against after a few days. 

Attachment 1: RGAscan_151019.png
RGAscan_151019.png
  4082   Tue Dec 21 11:52:58 2010 josephbUpdateComputersRGA scripts fixed, c0rga fixed

c0rga apparently had a full hard drive.  There was 1 Gig log file in /var/log directory, called Xorg.0.log.old which I deleted which freed up about 20% of the hard drive.  This let me then modify the crontab file (which previously had been complaining about no room on disk to make edits).

I updated the crontab to look at the new scripts location, updated the RGA script itself to write to the new log location, and then created a soft link in the /opt directory to /cvs/cds/rtcds on c0rga.

The RGA script should now be running again once a day.

  14438   Thu Feb 7 13:55:25 2019 gautamUpdateVACRGA turned on

[chub, steve, gautam]

Steve came by the lab today. He advised us to turn the RGA on again, now that the main volume pressure is < 20 uTorr. I did this by running the RGAset.py script on c0rga - the temperature of the unit was 22C in the morning, after ~3 hours of the filament being turned on, the temperature has already risen to 34 C. Steve says this is normal. We also opened VM1 (I had to edit the interlocks.yaml to allow VM1 to open when CC1 < 20uTorr instead of 10uTorr), so that the RGA volume is exposed to the main volume. So the nightly scans should run now, Steve suggests ignoring the first few while the pumpdown is still reaching nominal pressure. Note that we probably want to migrate all the RGA stuff to the new c1vac machine.

Other notes from Steve:

  • RP1 and RP3 should have their oil fully changed (as opposed to just topped up)
  • VABSSCI adn VABSSCO are NOT vent valves, they are isolating the annuli of the IOO and OMC chambers from the BS chamber annuli. So next time we vent, we should fix this!
  • Leak rate of 3-5 mTorr/day is "normal" once the system has been pumped for a few days. Steve agrees that our observations of the main volume pressure increase is expected, given that we were at atmosphere.
  • Regarding the upcoming CES construction
    • Steve recommends keeping the door along the east arm, as it is useful for bringing equipment into the lab (end door access is limited because of end optical tables)
    • Particle counter data logging should be resumed before the construction starts, so that we can monitor if the lab is getting dirtier
  • OSEM filters (new ones, i.e. made according to spects in D000209) are in the Clean Cabinet (EX). They are individually packaged in little capsules, see Attachment #1. So the ones I installed were actually a 2002 vintage. We have 50pcs, enough to install new ones on all the core optics + spares.
  1974   Tue Sep 8 16:01:52 2009 steveConfigurationVACRGA was separeted from IFO

The RGA isolation valve VM1 was closed since Aug 24, 2009  I installed the new UPS that time.

The last RGA scan in the log is from Aug 7, 2009   The vacuum rack UPS failed on Aug 15, 2009

I opened VM1 today so we can have ifo rga scan tomorrow.

 

Attachment 1: vm1closed.jpg
vm1closed.jpg
  139   Thu Nov 29 11:10:54 2007 robOmnistructureVACRGAlogger sleeping
Without the RGA controller responding, the RGAlogger script just hangs. Rather than fix it, I just put it to sleep by commenting out the line in op440m crontab file. Once we get it running again, we'll move the cronjob to op340m.
  10224   Thu Jul 17 00:38:30 2014 JenneUpdateLSCRIN in arm transmission

[Rana, Jenne]

We had a look at the RIN of the transmission signals TRX and TRY, when the arms were individually locked on IR.  If the intensity noise is very bad, then the transmission signals aren't really a good option to use for locking.  So, if the RIN is bad, we need to work on our intensity stabilization. 

We need to understand what the situation is with the AOM, and why it isn't working as expected, so that we can reinstall it.  We also need to decide if we're going to use the SR560 setup, or if the Chas ISS is sufficiently characterized for us to use. 

The RIN is certainly bad.  Also, I don't know why the Xarm's RIN is worse between 10 Hz and a few hundred Hz than the Yarm.

TransRIN.pdf

  10241   Sat Jul 19 17:36:44 2014 JenneUpdateLSCRIN in arm transmission

I looked at what the RIN contribution of the sqrtInv sensor is by locking the arms individually on IR using POX and POY.  I then took spectra of the sqrtInv channels.  For the Xarm, I had forced the triggering so that the QPD was being used as the transmission PD, while the Yarm was using the regular Thorlabs PD.  I also had the green lasers locked to the arms, and took beatnote spectra to see what the sensing noise of the beatnotes is, all at the same time.

For the sqrtInv channels, I used the Optickle calibration from elog 10187. For today's plot, I am using the calibration at about 1nm, since that is about where we are when we transition to the sqrtInv Thorlabs signal usually.

For the ALS channel, I was using the _FINE_PHASE_OUT signal, which is in units of degrees of phase for a single green wavelength.  So, since k * x = phi, I want the phase data to be converted to radians (2*pi/360), and use k = 2*pi / lambda_green.  So, doing some algebra, this gives me x = phi_degrees * lambda / 360 for my calibration. 

What I see in the plot is that the ALS sensing noise is pretty bad compared to the sqrtInv channels, so maybe we don't have to work so hard on the ISS this next week.  Also, the Thorlabs PD is much better than the QPDs, which maybe isn't so surprising since we have them set so that they have good SNR at higher power.

Anyhow, here's the plot:

TransSqrtInvRIN_vs_ALSsensing_18July2014.png

Also, here is the Thorlabs PD only, with single arm locked on RF, with the noise calibrated to different CARM offsets:

ThorlabsRIN_16July2014.png

  10242   Sat Jul 19 20:51:51 2014 KojiUpdateLSCRIN in arm transmission

Your calibration of the ALS signal should be revised.

The phase for the ALS is not an optical phase of the green but the phase of the phase tracker servo output.

The calibration of the phase tracker depends on the cable length of the delay line in the beat box.
It seems that we are based on this calibration. Which gives up ~19kHz/deg.

Or, equivalently, use C1:.....PHASE_OUT_HZ instead.

  10258   Wed Jul 23 02:01:15 2014 JenneUpdateLSCRIN in arm transmission - revised calibration

 

As Koji pointed out, I messed up the calibration.  However, fixing it doesn't change things that much.

From this calibration by Yuta, the Xarm ALS calibration is 54 deg / MHz, or 19.17 kHz / deg.  So, I multiply my data which is in these degree units by 19.17e3 to get Hz.  Then I use delta_f / f = delta_L / L to convert to meters.  f = c / lambda_green, and L = 37.5 meters. 

This only changes the calibration by about 10-15%.  It still looks like the ALS noise is well above the RIN level of the sqrtInv signal.

TransSqrtInvRIN_vs_ALSsensing_18July2014.png

  10703   Wed Nov 12 18:08:35 2014 JenneUpdateLSCRIN in transmission a problem?

In my previous meditations about RIN, particularly elog 10258, I was only thinking about the RIN contribution at the offset that I was currently sitting at.  Also, In elog 10258 I was comparing to the ALS signals and just said that the trans signals are better which is true, although isn't super helpful when thinking of reduced CARM offsets. 

My summary today is that I think we want to reduce the RIN in arm transmissions by a factor of 3.


Rather than dig around, I just remeasured the RIN, for both the single arm transmissions and the MC transmission.  (Data attached as .xml file)

The RMS RIN for the Xarm is 1.3e-2.  The RMS RIN for the Yarm is 8.9e-3.  The RMS RIN for MCtrans is 4.0e-3.  For the simulations below, I will use 1e-2 as an average RIN for the arms.

RIN_TRX_TRY_MCtrans_12Nov2014.pdf


As an estimate of the RIN's contribution to cavity fluctuations, I divide the RIN by the slope of the CARM transmission peak.  The slope (from optickle) gives me [ delta-W / delta-m ], and the inverse of that gives me [ delta-m / delta-W ].  I multiply this by RIN, which is [ delta-W / W ] to get [delta-m / W]. 

Then, since I'm using the DC transmission signals as my error signals, I use just TRX (normalized to be 1 for single arm resonance) as my Watts.

So, in total, the traces plotted are { TRX * RIN / slope }. 

The 2 plots are the same data, one with linear-x and the other with log-x.  They both include my estimate of the cavity length fluctuations due to RIN at the arm transmission, as well as an estimate of the cavity length fluctuations if the arm RIN was as good as the MC RIN.  I also show the DRFPMI CARM linewidth (23 pm for HWHM), and 1% of that linewidth.  The last trace is 1% of the half-width of the transmission peak, at the current CARM offset.  For example, 1000 pm away from full resonance the half-width is 1000 pm and 1% of that is 10 pm. 

 RINcontribution_12Nov2014_linearXscale.pngRINcontribution_12NOv2014_logXscale.png

What we want to see here is that the solid blue line is below one of the dotted lines.  I think that using the overall linewidth (purple dotted line) isn't really the right thing to look at.  Our goal is to prevent excursions that will get too close to the resonance peak, and cause a lockloss.  A one picometer excursion is a much bigger problem (relatively) below say 100 pm, as opposed to above 100 pm.  So, I think that we should be looking at the half-width of the resonance peak at whatever the current CARM offset is (orange dotted line).  Above 25 pm, the blue line is below the orange line for all offsets plotted.  If we made the arm RIN as good as the MC RIN, that would be true down to 12-ish pm. 

We should be able to safely transition to non-normalized RF signals at 10pm or below.  This implies that (since any RF signals normalized by this RIN-y trans signal will have the RIN), we want to improve the RIN of the transmission PDs by about a factor of 3. (This will lower the blue line such that it crosses the orange dotted line at 10 pm).

 

Attachment 1: RIN_TRX_TRY_MCtrans_12Nov2014_zip.xml.gz
  10707   Thu Nov 13 01:00:37 2014 ranaUpdateLSCRIN in transmission a problem?

 

 I modified the MC2 trans optical setup a little bit: the reflection from the QPD was not dumped and so it was hitting the wall of the black box.

I angled the QPD slightly and moved the dump so that the reflection hit it. The leakage through the 50/50 steering mirror for the QPD was already being dumped and I made sure that that one stayed dumped on its razor dump. After doing this we turned off the WFS and re-aligned the MC2 trans beam onto the QPD to zero the pit/yaw signals. 

  10709   Thu Nov 13 04:28:28 2014 JenneUpdateLSCRIN in transmission a problem?

[Jenne, Rana, Koji]

We did some thinking on what could be causing the excess RIN that we see in the arm transmissions but not in the MC transmission.  Unfortunately, I don't think we have anything conclusive yet. 

We thought about:

  • Test mass oplevs
  • Input tip tilt jitter
  • MC motion

Oplevs

As Rana reported in elog 10708, we tuned the oplev servos for ITMX, ETMX, ITMY and ETMY.  They all now look like the new SRM oplevs that Rana described in elog 10694.  However, when we re-looked at the RIN after the oplev tuning, we did not see a noticeable change.  So, fixing up the oplevs didn't fix up the RIN.

Side notes:

  • Several optics had low gains for suspos, which were increased to give Qs of ~5ish.
  • When we gave ITMX a 500 count step in pitch (the same size used for all other optics in both pit and yaw), it didn't come back afterward.  This is a little disconcerting.  Rana had to move the alignment slider to get it back so that we had MICH fringing at the AS port again.

Input Tip Tilts

Koji did some work, reported in elog 10706, on how much the jitter of the input pointing tip tilts should affect us.  We don't think that they are moving enough to be the cause of the excess RIN that we see.


Mode Cleaner Motion

We see some coherence between MC2 suspit and TRX/TRY, so we suspect that the MC's motion could be causing problems. 

I looked at the WFS vs. TRX & TRY, and saw significant coherence at the 3 Hz stack resonance.  I think it's clear that the WFS can help suppress this motion more.  The WFS noise level was too bad to see any other coherence at other frequencies. (Side note:  We should consider increasing the analog WFS signal.  As Rana mentioned back in 2008 in elog 454, the signal is super small.  Increasing the analog gain could allow us to suppress motion at more frequencies, although it would be a bit of a pain.)

To try and get some more signal, I routed the IPPOS beam over to the PRM oplev temporarily.  The idea was to be able to look at the IPPOS port, but with a fast channel.  I turned off the BS/PRM HeNe, and removed the last steering mirror before the QPD.  I put in 2 Y1 steering mirrors to get the IPPOS beam across the table and pointing at IPPOS.  I took my measurements 3 times, with different beam sizes on the QPD, to try to image different gouy phases.  I used absorptive ND filters (0.6 + 0.1) to get the light level on the PD such that I had about 10,000 counts per quadrant, where 16,000 counts seemed to be the saturation point. I also reset the dark offsets of the QPD quadrants, although they were so small that I don't think it did much.  I also took out the optical lever calibration from counts to microradians, since that number isn't meaningful for what I was doing.  So, the IPPOS signals (using the PRM oplev channels) are in raw ADC counts.  The first measurement had no lens, and the beam was probably at least half the size of the QPD.  The second measurement had a lens, and the beam on the QPD was about half the original size.  The third measurement had the lens closer to the QPD, so that the beam was about 1mm on the diode.  In none of these cases do I see any significant coherence with the TRX/TRY RIN signals, except at 3 Hz. After my measurements I put the oplev back including all of the digital settings, although for now I just left the IPPOS beam dumped on a razor dump, since it wasn't being used anyway.  I need to realign IPPOS when it's not the middle of the night.

Some thoughts that we have:

  • Maybe it's time to resurrect seismic feedforward on MC length, to suppress some of this 3 Hz motion?
  • Maybe we should be using the MC_L path to offload some of the frequency feedback, so that we're not pushing on MC2 so hard (because if we have bad F2P coupling, this creates beam motion)

I have plots for each of my IPPOS vs. TRX/TRY measurements.  The data is attached.  For each, I looked at the transfer function between IPPOS (using the SUS-PRM_OPLEV channels) and TRX/TRY to get the 'calibration' between input beam motion and transmission RIN.  In all cases, at 3 Hz the coefficient was about 1, so in the power spectra on the right side, there is no calibration applied to the IPPOS signals. 

IPPOS vs. Transmission RIN, no lens, big beam on QPD:

RIN_TRX_TRY_IPPOS_NoLens_12Nov2014.pdf

(Just kidding about the other 2 plots - the elog can't handle it.  They're in the zippyzip file though, and I don't think they look qualitatively different from the no-lens case).

 

Attachment 1: zippyzip.zip
  10720   Fri Nov 14 20:31:13 2014 ericqUpdateLSCRIN in transmission a problem?

I took a quick look at single arm RIN. Actuating on MC2 vs. the ETM, or using AS55 instead of POY11 made no noticeable difference in the arm cavity RIN.  Not too surprising, but there it is.

  10294   Wed Jul 30 09:33:33 2014 SteveUpdateSUSRIN of HeNe lasers

From old 40m elog 5-29-2007

Attachment 1: RINHeNe.pdf
RINHeNe.pdf
Attachment 2: RINHeNe2.pdf
RINHeNe2.pdf
Attachment 3: RINHeNe2.pdf
RINHeNe2.pdf
Attachment 4: RINHeNe3.pdf
RINHeNe3.pdf
  10712   Thu Nov 13 23:42:01 2014 JenneUpdateLSCRIN vs. Seismic

After Kate, Diego and I moved the seismometers to the corner for a huddle test (see elog 10711), I wanted to check the coherence between the seismometers and the arm transmissions.  

First of all, it looks like either the Guralp or the T-240 have their X and Y backwards. Diego is going to check this tomorrow. 

Between 0.9Hz - 3.5Hz, we have pretty strong coherence with the horizontal seismic channels.  Interestingly, between 8-10Hz, the Yarm has pretty strong coherence with the Z-axes of the seismometers (the coherence is only about 0.6, but it's consistent over a 2-ish Hz wide band). 

The MC transmission doesn't have as much coherence with the seismic, which surprised me.  So, we can try some FF to the MC, but we may also have to do some to the arms.

Seismic_TRXTRYandMC_13Nov2014.pdf

  10718   Fri Nov 14 17:08:17 2014 JenneUpdateLSCRIN vs. Seismic

T-240 has a different convention than we use.  It assumes that North is aligned with the Y-axis.  Since this is the new guy, and we've been using the Guralps with North = X for many years, Diego and I rotated the T-240, and put a label on it that N/S is Y, and E/W is X.  Obviously Vert is still Z.

  16335   Thu Sep 16 00:00:20 2021 KojiUpdateGeneralRIO Planex 1064 Lasers in the south cabinet

RIO Planex 1064 Lasers in the south cabinet

Property Number C30684/C30685/C30686/C30687

Attachment 1: P_20210915_232426.jpg
P_20210915_232426.jpg
  11078   Thu Feb 26 16:37:21 2015 manasaFrogsLSCRIP illegal power supply

No more illegal power supply at the LSC rack yes

The amplifiers are now being powered by the rack power supply through fuse blocks.

To make new connections, I shutdown the +/-15 V low noise power supplies. They were turned back ON after the work.

Quote:

 Is this your illegally installed HP bench power supply?

20131023_222351.jpg

If so, or if not but you care about the signal that passes through these amplifiers, I suggest you remove this temporary power supply and wire the power from the rack power supplies through the fuse blocks and possibly use a voltage regulator.

In 24 hours, that power supply will be disconnected and the wires snipped if they are still there.

 

  7019   Tue Jul 24 15:17:10 2012 MashaUpdatePEMRMS Filters, PEM Sitemap

RMS Filters

How Den, Rana, and I chose RMS filters:

- Because filter ring-down generates negative outputs, which then show up as NaN when the log is taken in StripTool, we decided to only use low-pass filters with real poles (using ZPK in Foton).

- The band-pass filters were chosen by looking at the dB drop from the cutoff frequencies to the next (usually aiming for 40 dB, or 99%), and checking that the BP_IN and BP_OUT had a coherence of 1 in the pass-band.

- The low-pass filters were chosen by finding the lowest filter order at which there was coherence of ~1 in the passband between the input signal to the filter and the filter output. The cutoff frequencies were chosen to be lower than the first passband frequency, in order to get rid of the cos(2*\omega*t)/2 terms that arise during the squaring of a signal of the form Asin(\omega*t) and to assure that only terms related to A^2/2 were kept. A plot of the 3-10 region is attached - in the Coherence plot, the coherence in ~1 in the 3 to 10 hZ region. Likewise,

PEM Sitemap

My previous post had digital zeros in two of the BLRMS channels. Jenne figured out that this was because the file Csqrt.c, which performs the square root operation in the root-mean square processing only accepted 5 inputs. I modified and committed the code so that it now accepts 7 inputs (for our 7 frequency bands) and returns 7 outputs. The new PEM sitemap seems to currently work.

StripTool

I have modified the StripTool file in order to show our new 0.01 Hz - 0.03 Hz and 0.03 Hz - 0.1 Hz channels.

Attachment 1: GUR1Z0p3to1FilterCoherence.png
GUR1Z0p3to1FilterCoherence.png
Attachment 2: GUR1Z3to10FilterCoherence.png
GUR1Z3to10FilterCoherence.png
Attachment 3: GUR1Z3to10FilterSignal.png
GUR1Z3to10FilterSignal.png
  8836   Fri Jul 12 12:51:13 2013 CharlesUpdateISSRMS Noise from PMC Transmission

I went out on the floor to look at the transmitted signal from the PMC to get a rough idea of the noise of the unstabilized laser. There was already a scope hooked up so I just used the measurement features to find the following:

Signal average = 875 mV.  Peak-to-Peak noise = 45 mV

Assuming the noise can be approximated as Gaussian noise, the heuristic for converting to RMS noise of the signal is RMS = Peak-to-Peak / 8 (or Peak-to-Peak / 6, I've used both...)

-> RMS Noise ~ 6.5 mV

When designing my filtering stages and RMS detection/triggering, I'll use relative RMS, i.e. 6 mV / 875 mV = 0.007, as a measure of unstabilized laser noise.

  8838   Fri Jul 12 13:15:43 2013 KojiUpdateISSRMS Noise from PMC Transmission

It would be better to measure the power spectrum density of the fluctuation.
The RMS does not tell enough information how the servo should be.
In deed, the power spctrum density gives you how much the RMS is in the entire or a specific frequency range.

  8839   Fri Jul 12 18:30:20 2013 CharlesUpdateISSRMS Noise from PMC Transmission

Quote:

It would be better to measure the power spectrum density of the fluctuation.
The RMS does not tell enough information how the servo should be.
In deed, the power spctrum density gives you how much the RMS is in the entire or a specific frequency range.

I wanted the RMS noise simply to establish a very rough estimate of thresholds on RMS detectors that will be part of my device. If you refer to elog 8830, I explain it there. Essentially, when the ISS is first engaged, only one of the 2 or 3 filter stages will be active. Internal RMS threshold detection serves to create a logic input to switch subsequent filters to their 'on' stage.

  8830   Thu Jul 11 13:52:51 2013 CharlesUpdateISSRMS threshold detection and triggering

There are essentially two major portions of the ISS I am designing. One system has the voltage reference, differential amplifier and filtering servo (schematic attached) while the other has a comparator circuit and a triggering mechanism. The first system amplifies an error signal obtained from the PD output and the voltage reference, which is then fed back through the AOM. I've done a lot of work designing/prototyping this first half and now I'm starting to design the second half.

The second system's main purpose is to maintain loop stability as the ISS is engaged. Let's assume a user has decided they want noise suppression. They would first close the ISS feedback loop and an error signal would pass through three unity-gain buffers, providing minimal noise reduction. The user can then send a signal to theTRIGGER 1 port to switch the first stage from its unity-gain position to its filtering position and reduce the intensity noise further. This signal will most likely be digital in origin. Alternatively, when the user first closes the ISS loop, the first stage can already be in its filtering position rather than necessitating two commands.

A test channel (not drawn in the included schematic) will monitor the RMS level of the incoming signal from the PD. This noisy AC signal will first be amplified and then passed through an RMS-to-DC converter. The resulting DC signal is used as a part of the triggering mechanism for later stages. Once the first stage has been switched manually, and the DC signal corresponding to RMS noise of the PD output drops below a certain threshold, stages 2 and 3 will be internally triggered with a short delay between them. Toward being able to detect this threshold, I have designed a simple comparator circuit with an LT1016. The circuit has a fairly low-level output when the input voltage is larger than the threshold (about 1.6 V for my simple prototype), but when the input passes below the threshold, the comparator puts out almost 4 V, a number limited by the supply voltage. The schematic is shown below.

Simple_Comparator_Circuit.png

The component V2 and the various voltage dividers serve to establish the reference/threshold voltage. Note that although the LT1016 is not powered in the schematic, it requires ±5 V (a max of 7 V). The above circuit was also prototyped on a breadboard and I characterized it with an oscilloscope. Using a CFG253, I made a low frequency (~0.3 Hz) triangle wave with an amplitude and DC offset such that it oscillates between 0 and 5 V. This was applied to the IN node in the above schematic. The input waveform and the circuit's response (voltage at the OUT node) are shown below. As expected, R2 serves to establish hysteresis. The comparator switches to 'high' output until the input drops below 1.6 V, and then it doesn't switch back to the 'low' output until the input goes up to ~3.4 V.

F0001TEK.JPG

This behavior is ideal for our application as we can detect when the DC signal from the RMS-to-DC converter drops below a certain level (i.e. the first stage that has been activated does some amount of filtering to lower RMS noise), and then we can trigger subsequent filter stages off of the comparators high-level output. 

This circuit could easily be used to drive the MAX333a switches shown in the first schematic attached. I believe the low-level output is not sufficient to switch the MAX333a although the ~4 V high-level output is quite sufficient. Regardless, these exact values (thresholds, outputs etc) will be determined after I have a better idea of the RMS noise of the laser without any intensity stabilization as well as a solid understanding of how the AD8436 RMS-to-DC converter works. This was simply a proof of concept for lower threshold detection using basic Schmitt trigger topology.

Attachment 1: 40mServo_v1.pdf
40mServo_v1.pdf
  11134   Wed Mar 11 19:15:03 2015 KojiSummaryLSCROUGH calibration of the darm spectrum during the full PRFPMI lock

I made very rough calibration of the DARM spectra before and after the transition for the second lock on Mar 8.

The cavity pole (expected to be 4.3kHz) was not compensated. Also the servo bump was not compensated.

[Error calibration]

While the DARM/CARM were controlled with ALS, the calibration of them are provided by the ALS phase tracker calibration.
i.e 1 degree = 19.23kHz

This means that the calibration factor is

DARM [deg] * 19.23e3 [Hz/deg] / c [m Hz] * lambda [m] * L_arm [m]
= DARM* 19.23e3/299792458*1064e-9*38.5 = 2.6e-9 *DARM [m]

[Feedback calibration]

Then, the feedback signal was calibrated by the suspension response (f=1Hz, Q=5)
so that the error and feedback signals can match at 100Hz.

This gave me the DC factor of 5e-8.


The spectra at 1109832200 (ALS only, even not on the resonance) and 1109832500 (after DARM/CARM transitions) were taken.
Jenne said that the whitening filters for AS55Q was not on.

Attachment 1: 150308_DARM_ROUGH_CALIB.pdf
150308_DARM_ROUGH_CALIB.pdf
  13365   Fri Oct 6 12:56:40 2017 gautamSummaryLSCRTCDS NN

[gabriele, gautam]

Gabriele had prepared a C code implementation of his NN for MICH/PRCL state estimation. He had been trying to get it going on some of the machines in WB, but was unsuccessful. The version of RCG he was trying to compile and run the code on was rather dated so we decided to give it a whirl on our new RCG3.4 here at the 40m. Just noting down stuff we tried here:

  • Code has been installed at /opt/rtcds/userapps/release/cds/c1/src/nn.This is to facilitate compilation by the RCG.
  • There is also a simulink block diagram (x3tst.mdl) in there which we copied and pasted into c1pem. Changed the appropriate paths in the C-Code block to point to the location in the previous bullet point.
  • c1pem was chosen for this test as it runs at 2k which is what the network is designed for.
  • Since we were running the test on c1sus and expected the machine to crash, I shutdown all the watchdogs for the test.
  • Code compiled without any problems (i.e. rtcds make c1pem and rtcds install c1pem executed successfully). There were some warning messages related to C-Code blocks but these are not new, they show up in all models in which we have custom C-code blocks. 
  • Unfortunately, the whole c1sus FE crashed when we tried rtcds restart c1pem.
  • We tried a couple of more iterations, and attempted to monitor dmesg during the restart process to see if there were any clues as to why this wasn't working, but got nothing useful.

All models have been reverted to their state prior to this test, and everything on the CDS_OVERVIEW MEDM screen is green now.

Attachment 1: post_NN_test.png
post_NN_test.png
  14122   Wed Aug 1 19:41:15 2018 gautamSummaryComputersRTCDS recovery, c1ioo changes

[Gautam Koji]

After this work, we recovered the nominal RTCDS state. The main points were:

  1. We needed to restart the bind9 service on chiara such that the FEs knew their IP addresses upon reboot and hence, could get their root filesystems over NFS.
  2. We recovered suspension local damping, IMC locking and POX/POY locking with nominal arm transmission.

Some stuff that is not working as usual:

  1. The EX QPD is reporting strange transmission values - even with the PRM completely misaligned, it reports transmission of ~30. But we were able to lock the Xarm with the Thorlabs PD and revover transmission of ~1.15.
  2. The X arm green does not stay locked to the cavity - the alignment looks fine, and the green flashes are strong, but the lock does not hold. This shouldn't be directly connected to anything we did today since the Green PDH servo is entirely analog.

I made a model change in c1x03 (the IOP model on c1ioo) to add a DAC part. The model compiled, installed and started correctly, and looking at dmesg on c1ioo, it recognises the DAC card as what it is. Next step is to use a core on c1ioo for a c1omc model, and actually try driving some signals.

Note that the only change made to the c1ioo expansion chassis was that a DAC card was installed into the PCIe bus. The adaptor card which allows interfacing the DAC card to an AI board was already in the expansion chassis, presumably from whenever the DAC was removed from this machine.

*I think I forgot to restart optimus after this work...

Attachment 1: CDS_overview.png
CDS_overview.png
  15950   Sun Mar 21 19:31:29 2021 ranaSummaryElectronicsRTL-SDR for monitoring RF noise / interference

When we're debugging our RF system, either due to weird demod phases, or low SNR, or non-stationary noise in the PDH signals, its good to have some baseline measurements of the RF levels in the lab.

I got this cheap USB dongle (RTL-SDR.COM) that seems to be capable of this and also has a bunch of open source code on GitHub to support it. It also comes mith an SMA coax and rabbit ear antenna with a flexi-tripod.

I used CubicSDR, which has free .dmg downloads for MacOS.It would be cool to have a student write some python code (perhaps starting with RTL_Power) for this to let us hop between the diffierent RF frequencies we care about and monitor the power in a small band around them.

  6124   Thu Dec 15 11:47:43 2011 jamieUpdateCDSRTS UPGRADE IN PROGRESS

I'm now in the middle of upgrading the RTS to version 2.4.

All RTS systems will be down until futher notice...

  6125   Thu Dec 15 22:22:18 2011 jamieUpdateCDSRTS upgrade aborted; restored to previous settings

Unfortunately, after working on it all day, I had to abort the upgrade and revert the system back to yesterday's state.

I think I got most of the upgrade working, but for some reason I could never get the new models to talk to the framebuilder.  Unfortunately, since the upgrade procedure isn't document anywhere, it was really a fly by the seat of my pants thing.  I got some help from Joe, which got me through one road block, but I ultimately got stumped.

I'll try to post a longer log later about what exactly I went through.

In any event, the system is back to the state is was in yesterday, and everything seems to be working.

  6174   Thu Jan 5 20:40:21 2012 JamieUpdateCDSRTS upgrade aborted; restored to previous settings; fb symmetricom card failing?

After running into more problems with the upgrade, I eventually decided to abort todays upgrade attempt, and revert back to where we were this morning (RTS 2.1).  I'll try to follow this with a fuller report explaining what problems I encountered when attempting the upgrade.

However, when Alex and I were trying to figure out what was going wrong in the upgrade, it appears that the fb symmetricom card lost the ability to sync with the GPS receiver.  When the symmeticom module is loaded, dmesg shows the following:

[  285.591880] Symmetricom GPS card on bus 6; device 0
[  285.591887] PIC BASE 2 address = fc1ff800
[  285.591924] Remapped 0x17e2800
[  285.591932] Current time 947125171s 94264us 800ns 
[  285.591940] Current time 947125171s 94272us 600ns 
[  285.591947] Current time 947125171s 94280us 200ns 
[  285.591955] Current time 947125171s 94287us 700ns 
[  285.591963] Current time 947125171s 94295us 800ns 
[  285.591970] Current time 947125171s 94303us 300ns 
[  285.591978] Current time 947125171s 94310us 800ns 
[  285.591985] Current time 947125171s 94318us 300ns 
[  285.591993] Current time 947125171s 94325us 800ns 
[  285.592001] Current time 947125171s 94333us 900ns 
[  285.592005] Flywheeling, unlocked...

Because of this, the daqd doesn't get the proper timing signal, and consequently is out of sync with the timing from the models.

It's completely unclear what caused this to happen.  The card seemed to be working all day today, then Alex and I were trying to debug some other(maybe?) timing issues and the symmetricom card all of a sudden stopped syncing to the GPS.  We tried rebooting the frame builder and even tried pulling all the power to the machine, but it never came back up.  We checked the GPS signal itself and to the extend that we know what that signal is supposed to look like it looked ok.

I speculate that this is also the cause of the problems were were seeing earlier in the week.  Maybe the symmetricom card has just been acting flaky, and something we did pushed it over the edge.

Anyway, we will try to replace it tomorrow, but Alex is skeptical that we have a replacement of this same card.  There may be a newer Spectracom card we can use, but there may be problems using it on the old sun hardware that the fb is currently running on.  We'll see.

In the mean time, the daqd is running rogue, off of it's own timing.  Surprisingly all of the models are currently showing 0x0 status, which means no problems.  It doesn't seem to be recording any data, though.  Hopefully we'll get it all sorted out tomorrow.

  6173   Thu Jan 5 09:59:27 2012 JamieUpdateCDSRTS/RCG/DAQ UPGRADE TO COMMENCE

RTS/RCG/DAQ UPGRADE TO COMMENCE

I will be attempting (again) to upgrade the RTS, including the RCG and the daqd, to version 2.4 today.  The RTS will be offline until further notice.

  16428   Tue Oct 26 14:53:24 2021 KojiUpdateElectronicsRack

1. We have a rack at the 40m storage. We are free to take it to the lab. If there is a tag, tell the info to Liz. Let's move it to the lab tomorrow right after the meeting.

2. We have a few racks in WB B1 (Attachment 1). Liz and I checked a rack which looks suitable for us. 46U height. Caltech transport will move it to the lab.

Attachment 1: P_20211026_143814.jpg
P_20211026_143814.jpg
  16458   Mon Nov 8 18:42:38 2021 KojiSummaryBHDRack Layout / Power Strips
Rack # of units that
requires +18V
Power Source
1X3 (new rack) 15 1X3 U1/2
1X4 13 1X3 U1/2
1X5 8 or 9 (OL AA) 1X5 U40/41
1Y0 17 1Y0 U1/2
1Y1 15 1Y0 U1/2
1Y3 12 1Y3 U39/40
1X9 9 1X9 U38/39
1Y4 9

1Y4 U39/40

Notes:

  • There are 8 racks and there is only 7x 18V power strips. 1X5 could be the one without the power strip and to parasite with 1X3/4. Otherwise we need to modify some of the 24V power strips (no plan to use) into 18V by replacing the connectors.
  • We need total ~100 18V cables / We ordered 60x 3ft / 60x 3ft / 30x 10ft. Hopefully these are enough for our depand... I haven't checked the delivered number.
  • All the acromags are supposed to be powered with one voltage. I think they are supposed to run with +18V.
  • I didn't check the distribution of Sorensens through the lab. (i.e. how many we have / how many we need / ...)
Attachment 1: rack_plan.pdf
rack_plan.pdf
  14869   Tue Sep 10 16:10:40 2019 ChubUpdate Rack Update

Still removing old cable, terminal blocks and hardware.  Once new strain reliefs and cable guides are in place, I will need to disconnect cables and reroute them.  Please let me know dates and times when that is not going to interrupt your work! 

Attachment 1: 20190910_154018.jpg
20190910_154018.jpg
Attachment 2: 20190910_154006.jpg
20190910_154006.jpg
  2953   Wed May 19 16:09:11 2010 josephbUpdateCDSRacks to small for IO Chassis rails

So I discovered the hard way that the racks are not standard width, when I was unable to place a new IO chassis into the racks with rails attached.  The IO chassis is narrow enough to fit through without the rails however. 

I've talked to Steve and we decided on having some shelves made.  I've asked Steve to get us 6.  1 for each end (2), 1 for SUS, 1 for LSC, 1 for IO, and 1 extra.

  2809   Mon Apr 19 16:27:13 2010 AidanUpdateGreen LockingRaicol crystals arrived and we investigated them

Jenne, Koji and I opened up the package from Raicol and examined the crystals under the microscope. The results were mixed and are summarized below. There are quite a few scratches and there is residue on some of the polished sides. There is a large chip in one and there appear to be gaps or bands in the AR coatings on the sides.

There are two albums on Picassa

1. The package is opened ...

2. The crystals under the microscope.

 

Crystal Summary
724 Chip in the corner of one end face, Otherwise end faces look clean. Large scratch on one polished side.
725 End faces look good. Moderate scratch on one polished face. Residue on one polished face.
726 Tiny dot on one end face, otherwise look okay. Large bands in one polished face. Moderate scratch on polished face
727 Large, but shallow chip on one polished face. End faces look clean. Bands in one of the polished faces.

 

  2816   Tue Apr 20 11:14:31 2010 AidanUpdateGreen LockingRaicol crystals arrived and we investigated them

 

 Here is Crystal 724 polished side 2 with all photos along the length stitched together

  1939   Tue Aug 25 01:27:09 2009 ranaConfigurationComputersRaid update to Framebuilder (not quite)

Quote:

The RAID array servicing the Frame builder was finally switched over to JetStor Sata 16 Bay raid array. Each bay contains a 1 TB drive.  The raid is configured such that 13 TB is available, and the rest is used for fault protection.

The old Fibrenetix FX-606-U4, a 5 bay raid array which only had 1.5 TB space, has been moved over to linux1 and will be used to store /cvs/cds/.

This upgrade provides an increase in look up times from 3-4 days for all channels out to about 30 days.  Final copying of old data occured on August 5th, 2009, and was switched over on that date.

 Sadly, this was only true in theory and we didn't actually check to make sure anything happened.

We are not able to get lookback of more than ~3 days using our new huge disk. Doing a 'du -h' it seems that this is because we have not yet set the framebuilder to keep more than its old amount of frames. Whoever sees Joe or Alex next should ask them to fix us up.

  1901   Fri Aug 14 10:39:50 2009 josephbConfigurationComputersRaid update to Framebuilder (specs)

The RAID array servicing the Frame builder was finally switched over to JetStor Sata 16 Bay raid array. Each bay contains a 1 TB drive.  The raid is configured such that 13 TB is available, and the rest is used for fault protection.

The old Fibrenetix FX-606-U4, a 5 bay raid array which only had 1.5 TB space, has been moved over to linux1 and will be used to store /cvs/cds/.

This upgrade provides an increase in look up times from 3-4 days for all channels out to about 30 days.  Final copying of old data occured on August 5th, 2009, and was switched over on that date.

  427   Fri Apr 18 16:48:13 2008 AndreyUpdatePEMRain collector of weather station

Today the rain collector of our weather station was cleaned. As a result, we checked that the rain indication on the weather monitor and on the MEDM screens is alive and working properly. I am adding some details about the roof sensors to the wiki-40 page about the weather station. See especially the link "More description of the roof sensors and their interaction with UNIX computers" from the main Weather Station page in wiki-40.

Pictures of the rain collector before (dirty, the opening is fully clogged with dust and dirt) and after (clean opening in the bottom of the bowl) the cleaning are attached.
Attachment 1: DSC_0520--before.JPG
DSC_0520--before.JPG
Attachment 2: DSC_0537--after.JPG
DSC_0537--after.JPG
  11283   Mon May 11 15:15:12 2015 manasaUpdateGeneralRan ASS for arms

Arm powers had drifted to ~ 0.5 in transmission.

X and Y arms were locked and ASS'd to bring the arm transmission powers to ~1.

ELOG V3.1.3-