40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 155 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  14557   Fri Apr 19 15:13:38 2019 ranaUpdateSUSNo consistent solution for output matrix

let us have 3 by 4, nevermore

so that the number of columns is no less

and no more

than the number of rows

so that forevermore we live as 4 by 4 

Quote:

I'm struggling to think

  3121   Fri Jun 25 15:22:45 2010 JenneOmnistructureSAFETYNo entry to the 40m LVEA until further notice!

                                                                                                                                                                                                                                                                               

The 40m corner station crane is out of order, and it's stuck in a way that prohibits entry to the 40m LVEA / IFO room for safety.  The crane has been locked out / tagged out. 

Until further notice, absolutely no one may enter the 40m LVEA.  Work is permitted in the desk / control room areas.

Signs have been posted on all doors into the LVEA.  Please consider those doors locked out / tagged out.

                                                                                                                                                                                                                                                                               

  7715   Thu Nov 15 03:09:08 2012 JenneUpdateAlignmentNo good progress, many options
I didn't make any concrete progress today. AS and REFL cameras are in place, and Manasa has put ND 0.5 filters on both. I used a 
camera to look at the back of the Faraday, and aligned PRM such that it was retroreflecting, and then tried to align ITMY to have once 
fringes with the PRM at that place. I failed in this, since the AS beam on the AS table was starting to dall off the first mirror on the table. 
I then restored all the suspensions to where they were before I started touching them today. 

I moved ETMY face camera so that it is looking at the front of the black glass, but it's hard to tell where the beam is.  I was thinking 
about setting up a temporary camera to look at the back of ITMY to help guide PZT steering, but I haven't done this yet. 

Koji and I then talked about the several different options I have for references, and how many different knobs I  can turn. I'm sleeping 
on it for now, and hopefully I'll have more insight on what to do tomorrow. 
  816   Fri Aug 8 13:29:54 2008 YoichiUpdateSUSNo groove in the stand-off ... wait, it is not even a stand-off !
Yoichi, Steve, Seiji

We took magnified pictures of the stand-offs of the PRM.
Attm1: North side stand-off.
Attm2: South side stand-off.
Attm3: Zipped file of the full pictures.

We found no groove in the south side stand-off.
After some discussion, we concluded that it is actually a guide rod. You can see it from the size difference (the magnification is the same for the two pictures).
The stand off on the south side is missing (fell off, ran away, evaporated or whatever ...).
Also we noticed that the guide rod on the north side is missing.

We have to find a stand-off and place it on the south side.
Seiji suggested that it is better to put a guide rod next to the north side stand-off, otherwise the stand-off itself is too weak to hold the load.
He also said that the PRM was installed after he left, so it was not his fault.
Attachment 1: north-standoff-preview.jpg
north-standoff-preview.jpg
Attachment 2: south-standoff-preview.jpg
south-standoff-preview.jpg
Attachment 3: No-groove.zip
  817   Fri Aug 8 15:10:35 2008 YoichiUpdateSUSNo groove in the stand-off ... wait, it is not even a stand-off !
I tried to find the missing stand-off and the guide rod in the BS chamber, but I couldn't.
  11089   Tue Mar 3 02:43:06 2015 JenneOmnistructurePEMNo heat??

It's super cold in the control room and EE bench area tonight.  I'm wondering if, similar to what happened on Dec 29th (http://nodus.ligo.caltech.edu:8080/40m/10846) the campus steam is off?  Or just our heater is broken?  The thermostat is cranked up to 80 over by the bathrooms (this is usually ~74F), but we're still cold.

It's 69F in the control room right now (usually mid-high 70s).

EDIT, JCD, 4am: It's 64.3F in the desk area, 67.8F in the control room.  It also smells in the control room like some heater has been off for a while, and is turning back on - that burned dust smell that happens after you haven't turned on the heater all summer. 

EDIT again: The burn-y smell is getting stronger I think.  Security is sending someone over to come check it out.

  12893   Mon Mar 20 11:18:58 2017 gautamUpdateCDSNo internet connectivity on control room machines

There is no internet connectivity on any of the control room machines. 

I have been trying to debug by tracing the cabling situation in the rack in the office area, and will update if/when this problem has been resolved. I had last come into the lab on Saturday and there was no problem then. There 40m wireless network servicing the office area seems to work fine.

 

  12894   Mon Mar 20 14:39:44 2017 gautamUpdateCDSNo internet connectivity on control room machines

Koji diagnosed that the NAT router was to blame for this problem. I simply power cycled this router, and now the connectivity has been restored. 

It was possible to log into nodus and then to pianosa - and it was also possible to log into the various control room machines once logged into nodus. However, the outward packets seemed to not get transmitted. Anyways, power cycling the NAT Router unit seems to have done the job.

Quote:

There is no internet connectivity on any of the control room machines. 

I have been trying to debug by tracing the cabling situation in the rack in the office area, and will update if/when this problem has been resolved. I had last come into the lab on Saturday and there was no problem then. There 40m wireless network servicing the office area seems to work fine.

 

 

  10562   Fri Oct 3 03:02:17 2014 ericqUpdateLSCNo luck locking DRMI

I haven't been able to lock the DRMI tonight, neither with 1F and no arms nor 3F and arms held off with ALS... I tried previous recipes, and new combinations informed by simulations I've run, to no avail. 

I touched the alignment of the green beat PD on the PSL table, since the X beatnote was rather low, but wasn't able to improve it by much. I never took a spectrum, since it wasn't my main focus tonight, but the low frequency motion of both arms on ALS, as observed by RIN, was good as I've ever seen it. 

In our WFS work earlier today, Koji and I reset the WFS offsets, and it actually seems to have helped a good deal, in terms of the "fuzz" of MC REFL on the wall striptool. I had previously presumed this to be due to excess angular motion, but perhaps it is more accurately described as an alignment offset that let the nominal angular motion couple into the RIN more. 

  11997   Wed Feb 17 13:45:15 2016 ericqUpdateGeneralNo monit on frontends

daqd has indeed continued to be unstable. I found system times had drifted apart again... I think something weird happened in the booting of the frontends. The monit processes were not running on any of the frontends. I ntpdate'd again, and manually started monit on each fronted via sudo /etc/init.d/monit start

  9771   Tue Apr 1 20:56:27 2014 JenneUpdatePEMNo noticeable effect from Chile's M8.2 earthquake

Koji locked the MC, arms, and PRMI, with no troubles, after the M8.2 earthquake off the coast of Chile, that happened about 4 hours ago.

  11309   Tue May 19 11:50:52 2015 manasaUpdatePEMNo noticeable effect from M4.0 earthquake

There was an earthquake: M4.0 - 40km SSW of South Dos Palos, California 

No noticeable effects on the IFO. MC did not lose lock; however the arms did unlock.

  2520   Mon Jan 18 09:44:36 2010 Alberto, BobOmnistructureEnvironmentNo rain water infiltrations so far

It has rained continuously for the last 24 hours. Bob walked through the lab looking for possible water infiltrations. The floor looked dry: no puddles or leaks anywhere so far.

  2950   Tue May 18 23:03:08 2010 JenneUpdateIOONo real progress....

[Jenne, Kevin]

No real progress today.  We opened the chambers and again tried to lock the MC.  Gave up after ~2.5 hours (and closed up the chambers with light doors, replaced manual beam block, etc...).  With Koji's helpful coaching, hopefully we'll finally get it done tomorrow.  Then we can move forward with the actual to-do list. 

 

  15056   Wed Nov 27 23:24:01 2019 gautamUpdateLSCNo shaking but no inspiration either

Summary:

I tried the following minor changes to the locking procedure to see if there were any differences in the ALS noise performance:

  1. Actuate DARM only on one ETM (tried both ETMX and ETMY)
  2. Enable MCL and PRC seismic feedforward
  3. DC couple the ITM Oplevs for better angular stability during the lock acquisition

None of these changes had any effect - the ALS noise still goes up with arm buildup. 

I think a good way to determine if the problem is to do with the IR part of the new ALS system is to resurrect the green beat setup - I expect this to be less invasive than installing attenuators/beam dumps in front of the fiber couplers at the ends. We should at the very least recover the old ALS noise levels and we were able to lock the PRFPMI with that config. If the excess noise persists, we can rule out the problem being IR scatter into the beat-mouth fibers. Does this sound like a reasonable plan?

  15057   Sun Dec 1 13:38:48 2019 ranaUpdateLSCNo shaking but no inspiration either

yes, reasonable

  6627   Wed May 9 00:45:13 2012 JenneUpdateCDSNo signals for DTT from SUS

Upgrades suck.  Or at least making everything work again after the upgrade.

On the to-do list tonight:  look at OSEM sensor and OpLev spectra for PRM, when PRMI is locked and unlocked.  Goal is to see if the PRM is really moving wildly ("crazy" as Kiwamu always described it) when it's nicely aligned and PRMI is locked, or if it's an artifact of lever arm between PRM and the cameras (REFL and AS).

However, I can't get signals on DTT.  So far I've checked a bunch of signals for SUS-PRM, and they all either (a) are just digital 0 or (b) are ADC noise.  Lame.

Steve's elog 5630 shows what reasonable OpLev spectra should look like:  exactly what you'd expect.

Attached below is a small sampling of different SUS-PRM signals.  I'm going to check some other optics, other models on c1sus, etc, to see if I can narrow down where the problem is.  LSC signals are fine (I checked AS55Q, for example).

UPDATE:  SRM channels are same ADC noise.  MC1 channels are totally fine.  And Den had been looking at channels on the RFM model earlier today, which were fine.

ETMY channels - C1:SUS-ETMY_LLCOIL_IN1 and C1:SUS-ETMY_SUSPOS_IN1 both returned "unable to obtain measurement data".  OSEM sensor channels and OpLev _PERROR channel were digital zeros.

ETMX channels were fine

UPDATE UPDATE:  Genius me just checked the FE status screen again.  It was fine ~an hour ago when I sat down to start interferometer-izing for the night, but now the SUS model and both of the ETMY computer models are having problems connecting to the fb.  *sigh* 

Attachment 1: OpLevs_OSEMs_allSUSchannels_ADCnoiseOnly.pdf
OpLevs_OSEMs_allSUSchannels_ADCnoiseOnly.pdf
Attachment 2: Screenshot.png
Screenshot.png
  6628   Wed May 9 01:14:44 2012 JenneUpdateCDSNo signals for DTT from SUS

Quote:

UPDATE UPDATE:  Genius me just checked the FE status screen again.  It was fine ~an hour ago when I sat down to start interferometer-izing for the night, but now the SUS model and both of the ETMY computer models are having problems connecting to the fb.  *sigh* 

 Restarted SUS model - it's now happy. 

c1iscey is much less happy - neither the IOP nor the scy model are willing to talk to fb.  I might give up on them after another few minutes, and wait for some daytime support, since I wanted to do DRMI stuff tonight.

Yeah, giving up now on c1iscey (Jamie....ideas are welcome).  I can lock just fine, including the Yarm, I just can't save data or see data about ETMY specifically.  But I can see LSC data, so I can lock, and I can now take spectra of corner optics.

  6630   Wed May 9 08:21:42 2012 JamieUpdateCDSNo signals for DTT from SUS

Quote:

 c1iscey is much less happy - neither the IOP nor the scy model are willing to talk to fb.  I might give up on them after another few minutes, and wait for some daytime support, since I wanted to do DRMI stuff tonight.

Yeah, giving up now on c1iscey (Jamie....ideas are welcome).  I can lock just fine, including the Yarm, I just can't save data or see data about ETMY specifically.  But I can see LSC data, so I can lock, and I can now take spectra of corner optics.

 This is the mx_stream issue reported previously.  The symptom is that all models on a single front end loose contact with the frame builder, as opposed to *all* models on all front end loosing contact with the frame builder.  That indicates that the problem is a common fb communication issue on the single front end, and that's all handled with mx_stream.

ssh'ing into c1iscey and running "sudo /etc/init.d/mx_stream restart" fixed the problem.

  3535   Tue Sep 7 15:57:07 2010 AlbertoConfigurationComputersNodus connection not working. Fixed

[Joe, Alberto]

The Nodus connection to the Martian network stopped working after someone switched cables on the Netgear router. Apparently that router doesn't like to have the 23 and 24 ports connected at the same time.

Joe fixed the connection just freeing either the 23 or the 24 port.

  463   Thu May 1 12:46:02 2008 josephbConfigurationComputersNodus gateway is up
The computer Nodus is now acting as a gateway machine between the GC network and the martian network in the 40m. It has the same passwords as the rana gateway machine.

Its name on the GC side is nodus (ip: 131.215.115.52) and on the martian side is nodus113 (ip: 131.215.113.200). Will need to update the hosts file on the control room machines so you can just use the name nodus113 rather than the full ip.

Software is still being added to the computer, and it will remain in parallel with the rana gateway machine until everything has been working properly for a week or so.
  13775   Fri Apr 20 16:22:32 2018 gautamUpdateGeneralNodus hard-rebooted

Aidan called saying nodus was down at ~345pm. I was able to access it at ~330pm. I couldn't ssh in from my machine or the control room ones. So I went to 1X7 and plugged in a monitor to nodus. It was totally unresponsive. Since the machine wasn't responding to ping either, I decided to hard-reboot it. Machine seemed to come back up smoothly. I had trouble getting the elog started - it wasn't clear to me that the web ports were closed by default, so even though the startELOGD.sh script was running fine, the 8080 port wasn't open to the outside world. Anyways, once I figured this out, I was able to start the elog. DokuWiki also seems to be up and running now... 

  473   Fri May 9 10:15:36 2008 josephbUpdateComputersNodus has moved
Steve and myself moved Nodus from under the table in the control room, to just above the Rana computer in the control room rack.
  10759   Fri Dec 5 15:41:45 2014 JenneUpdateComputer Scripts / ProgramsNodus on fast GC network

Apparently, some time ago Larry Wallace installed a new, fast ethernet switch in the old nodus rack. Q and I have just now moved nodus' GC ethernet cable over to the new switch.  Dan Kozak is going to use this faster connection to make the data flow over to the cluster not so lag-y.

  1887   Tue Aug 11 23:17:21 2009 ranaSummaryComputersNodus rebooted / SVN down

Looks like someone rebooted nodus at ~3 PM today but did not elog it. Also the SVN is not running. Why?

  1890   Wed Aug 12 10:35:17 2009 jenneSummaryComputersNodus rebooted / SVN down

Quote:

Looks like someone rebooted nodus at ~3 PM today but did not elog it. Also the SVN is not running. Why?

 The Nodus business was me....my bad.  Nodus and the elog were both having a bad day (we couldn't ssh into nodus from op440m (which doesn't depend on the names server)), so I called Alex, and he fixed things, although I think that all he did was reboot.  I then restarted the elog per the instructions on the wiki.

 

  11862   Tue Dec 8 15:18:29 2015 ericqUpdateComputer Scripts / ProgramsNodus security

I've done a couple things to try and make nodus a little more secure. Some have worried that nodus may be susceptible to being drafted into a botnet, slowing down our operations. 

1. I configured the ssh server settings to disallow logins as root. Ubuntu doesn't enable the root account by default anyways, but it doesn't hurt.

2. I installed fail2ban. Function: If some IP address fails to authenticate an ssh connection 3 times, it is banned from trying to connect for 10 minutes. This is mostly for thwarting mass brute force attacks. Looking at /var/log/auth.log doesn't indicate any of this kind of thing going on in the past week, at least.

3. I set up and enabled ufw (uncomplicated firewall) to only allow incoming traffic for:

  • ssh
  • ELOG
  • Nodus apache stuff (svn, wikis, etc.)

I don't think there are any other ports we need open, but I could be wrong. Let me know if I broke something you need!

  11869   Wed Dec 9 23:16:13 2015 ranaUpdateComputer Scripts / ProgramsNodus security

NDS2 and the usual ports so that we can use optimus as a comsol server.

Quote:

 

I don't think there are any other ports we need open, but I could be wrong. Let me know if I broke something you need!

 

  2595   Fri Feb 12 11:56:02 2010 josephbUpdateComputersNodus slow ssh fixed

Koji pointed out that logging into Nodus was being abnormally slow.  I tracked it down to the fact we had forgotten to update the address for the DNS server running on linux1 in the resolv.conf file on nodus.  Basically it was looking for a DNS server which didn't exit, and thus was timing out before going to the next one.  SSHing into nodus should be more responsive.

  2427   Thu Dec 17 09:30:08 2009 AlbertoHowToComputersNodus sluggish

The elog has been quite slow for the last two days. The cause is nodus, that has been slowing down the access to it.

I looked at the list of the running processes on nodus by typing the command prstat, which is the equivalent for Solaris of the Linux "top". I didn't see any particular process that might be absorbing too many resources.

I remember Rana fixing the same problem in the past but couldn't find his elog entry about that. Maybe we should just restart nodus, unless someone has some other suggestion.

  2429   Thu Dec 17 19:03:14 2009 AlbertoHowToComputersNodus sluggish

Quote:

The elog has been quite slow for the last two days. The cause is nodus, that has been slowing down the access to it.

I looked at the list of the running processes on nodus by typing the command prstat, which is the equivalent for Solaris of the Linux "top". I didn't see any particular process that might be absorbing too many resources.

I remember Rana fixing the same problem in the past but couldn't find his elog entry about that. Maybe we should just restart nodus, unless someone has some other suggestion.

 Problem solved. Nodus and the elog are running fine. It's just that the elog takes some time to make a preview of complex pdf attachments, like those in Kiwamu's entry 2405.

  11162   Mon Mar 23 22:56:54 2015 ericqUpdateComputer Scripts / ProgramsNodus web things

Back when Diego and I were getting all of the web services running up on the new nodus, we inexplicably were not able to get the hosting of the public_html directory and wikis to share the same port of 30889. In ELOG 10793, we stated that public_html was hosted on a new port, 30888, though we didn't really bring much attention to that new fact. 

Unbeknowst to us at the time, this broke other links/bookmarks/sites that people had been using. Koji pointed this out to me the other day, but I have not made any sort of resolution. For now, the public_html directory, and the sites therein, have been taken offline. 


In other nodus news, Jamie has set Nodus' apache service with a certificate for SSL goodness. We want to extend this to the ELOG, which uses a built in webserver, rather than apache. 

He set up a proxy at the https address which will later host the secured elog: https://nodus.ligo.caltech.edu:8081/

When we make the switch to running the ELOG with HTTPS on by default, living on port 8081, we will set up apache to point 8080 at 8081, to preserve all of the old links. 

I.e. this change should effectively be invisible to ELOG users if we implement it right. 

  535   Mon Jun 16 18:26:01 2008 Max JonesUpdateComputer Scripts / ProgramsNoise Budget Changes
In the directory cvs/cds/caltech/NB the following changes were made:

I created temporary files in ReferenceData for the C1 by copying and renaming the corresponding H1 files.
- C1_SRD_Disp.txt
- C1IFOparams.m
- C1_NoiseParams.m

In getmultichan.m I added a C1 case.

In NoiseBudget.m I added a C1 case with modified sources array to include only DARM and Seismic

I appreciate and suggestions. Max.


  364   Fri Mar 7 17:10:01 2008 Max JonesUpdateComputersNoise Budget work
Noise budget has been moved to the svn system. A checked out copy is in the directory caltech. From now on, I will try to use the work cycle as outlined in the svn manual. Changes made today include the following:
getNoiseBudget
/matlab/noise/NoiseBudget

Details of the modifications made may be found on the svn system. Please let me know if anyone has a suggestion or concern. Thank you - Max.
  16897   Tue Jun 7 18:32:46 2022 DeekshaUpdateElectronicsNoise Budgeting ADC (of redpitaya)

Made plots on i/p noise of redpitaya . Need to reconsider sampling frequency (to improve plot at lower freq)
 

Attachment 1: ch1_0.5V.png
ch1_0.5V.png
Attachment 2: ch2_0.0V.png
ch2_0.0V.png
  11880   Mon Dec 14 16:46:42 2015 ericqUpdateWienerFilteringNoise Subtraction Puzzler

Here's something to ponder.

Our online MCL feedforward uses perpendicular vertex T240 seismometer signals as input. When designing a feedforward filter, whether FIR Wiener or otherwise, we posit that the PSD of the best linear subtraction one can theoretically achieve is given by the coherence, via Psub = P(1-C). 

If we have more than one witness input, but they are completely uncorrelated, then this extends to Psub = P(1-C1)(1-C2). However, in reality, there are correlations between the witnesses, which would make this an overestimate of how much noise power can be subtracted. 

Now, I present the actual MCL situation. [According to Ignacio's ELOG (11584), the online performance is not far from this offline prediction]

Somehow, we are able to subtract much more noise at ~1Hz than the coherence would lead you to believe. One suspicion of mine is that the noise at 1Hz is quite nonstationary. Using median [C/P]SDs should help with this in principle, but the above was all done with medians, and using the mean is not much different.

Thinking back to one of the metrics that Eve and Koji were talking about this summer, (std(S)/mean(S), where S is the spectrogram of the signal) gives an answer of ~2.3 at that peak at 1.4Hz, which is definitely in the nonstationary regieme, but I don't have much intution into just how severe that value is.

So, what's the point of all this? We generally use coherence as a heuristic to judge whether we should bother attempting any noise subtraction in the first place, so I'm troubled by a circumstance in which there is much more subtraction to be had than coherence leads us to believe. I would like to come up with a way of predicting MISO subtraction results of nonstationary couplings more reliably.

Attachment 1: subpuzz.pdf
subpuzz.pdf
  11918   Thu Jan 7 15:29:54 2016 ericqUpdateWienerFilteringNoise Subtraction Puzzler

The puzzle continues...

I found some reference for computing "multicoherence," which should properly estimate the potential MISO subtraction potential in situations where the witness channels themselves have nontrivial coherence. Specifically, I followed the derivations in LIGO-P990002. The underlying math is related to principal component analysis (PCA) or gram-schmidt orthogonalization. 

This produced the following results, wherein the Wiener subtraction is still below what the coherences predict. 

I've attached the data and code that produced this plot. 

Attachment 1: subpuzz2.pdf
subpuzz2.pdf
Attachment 2: puzzle.zip
  11933   Thu Jan 14 15:08:37 2016 ericqUpdateWienerFilteringNoise Subtraction Puzzler

The anticlimatic resolution to my subtraction confusion: Spectral leakage around 1Hz. Increasing the FFT length to 256 sec now shows that the FIR WF pretty much achieves the ideal subtraction. 

If nothing else, it's good to have worked out how MISO coherence works.

Attachment 1: subpuzz_resolved.pdf
subpuzz_resolved.pdf
  11934   Thu Jan 14 18:41:36 2016 ranaUpdateWienerFilteringNoise Subtraction Puzzler

Just not just pedagogical !  Freq domain MISO coherence based subtraction estimation is much faster than calculating MISO WF. And since each bin is independent of each other, this gives us an estimate of how low the noise can go, whereas the Wiener filter is limited by Kramers-Kronig. We should be able to use this on the L1 DARM channel to do the noise hunting as well as estimating the subtraction efficacy of the pseudo channels that you and Rory come up with.

If you can code up a noise hunter example using DARM + a bunch of aux channels, we could implement it in the summary pages code.

  318   Thu Feb 14 17:21:53 2008 Max JonesUpdateComputersNoise budget code changes
In cvs/cds/caltech/NB/matlab/utilities/LSCmodel.m at line 146
I have hardwired in changes to struct lsc. Please see code.
  319   Fri Feb 15 10:28:44 2008 ranaUpdateComputersNoise budget code changes

Quote:
In cvs/cds/caltech/NB/matlab/utilities/LSCmodel.m at line 146
I have hardwired in changes to struct lsc. Please see code.

The IFOin variable (which I admit is not documented) should refer to a file called
C1IFOparams.m in the ReferenceData directory. This does not yet exist but can be
created by merging L1IFOparams.m with our knowledge of the 40m IFO.
  15482   Wed Jul 15 17:46:05 2020 anchalSummaryALSNoise budget for ALS

I started my attempt on noise budgeting of ALS by going back to how Kiwamu did it and adding as many sources as I could find up till now. This calculation is present in ALS_Noise_Budget notebook. I intend to collect data for noise sources and all future work on ALS in the ALS repo.

The noise budget runs simulink through matlab.engine inside python and remaining calculations including the pygwinc ones are done in python. Please point out any errors that I might have done here. I still need to add noise due to DFD and the ADC after it. For the residual frequency noise of AUX laser, I have currently used an upper limit of 1kHz/rt Hz at 10 Hz free-running frequency noise of an NPRO laser.

Attachment 1: ALS_nb.pdf
ALS_nb.pdf
  7904   Wed Jan 16 10:57:37 2013 taraSummaryIOONoise budget for MC

I calculated thermal noise in mode cleaner (MC) mirrors and compared it with the measured MC noise. Thermal noise won't be a significant noise source for MC.

== Motivation==

 There is an idea of using MC and a refcav to measure coating thermal noise. One laser is frequency locked to MC, another laser is locked to an 8" refcav. Then the two transmitted beams are recombined so that we can readout the frequency noise. In this case, the transmitted beam from MC is a better reference (less frequency noise) than the beam from refcav. However, we need to make sure that we understand the noise sources, for example brownian noise, thermoelastic noise in both substrates and coatings, in MC more thoroughly.

==Calculation==

I used Rana's code for MC's technical noise sources from, svn. The same plot can be found in appendix C of his thesis. Then I added my calculation to the plot.  Jenne pointed me to 40m:2984 for the spot size and the cavity length. The spot radius on MC1 and MC3 is ~ 1.5mm, and ~3.4 mm@MC2, The round trip length is ~27m, thus the frequency fluctuation due to thermal noise is lower than that of refcav by 2-3 orders of magnitude. I calculated Brownian noise in coatings, Brownian noise in substrate, Thermoelastic noise in substrate. I assumed that the coatings are SiO2/Ta2O5, quarter stacks, coatings thickness for MC1/3 = 5um, for MC2 = 8um. The code can be found in the attachment.

mc_nb_TN.png

==result==

Total thermal noise on MC (Brownian + Thermoelastic on substrate and coatings of MC1-MC3) is plotted in dashed red. It is already below 10^-5 Hz/rtHz at ~20 Hz. This is sufficiently low compared to other noise sources. Beat signal from CTN measurement with 8" cavities is plotted in pink, the estimated coating brownian noise is plotted in a yellow strip. They are well above the measured MC noise between 100 Hz to a few kHz. Measuring coating thermal noise on 8" refcav seems plausible with this method. We can beat the two transmitted beams from IMC and refcav and readout the beat signal to extract the displacement noise of refcav. I'll discuss this with Koji if this is a good surf project.

 mc_nb_TN_2013_01_18.png

[the internal thermal noise in the original plotted is removed and replaced with the total thermal noise plot instead]

 note:I'm not sure about the current 40m MC configuration. The parameters used in this calculation are summarized in mcnoiseS2L1.m (in the svn page).

 

Attachment 2: mc_nb_TN.png
mc_nb_TN.png
Attachment 3: mc_nb_TN.fig
Attachment 4: MC_nb.m.zip
  7908   Wed Jan 16 19:08:51 2013 KojiSummaryIOONoise budget for MC

I missed the point.
Do you mean that we can measure the coating thermal noise of the ref cav at the 40m as the IMC is quiet enough?

  7911   Thu Jan 17 01:27:54 2013 Tara(?)SummaryIOONoise budget for MC

Quote:

I missed the point.
Do you mean that we can measure the coating thermal noise of the ref cav at the 40m as the IMC is quiet enough?

 Yes, it should be. However, what I did was calculating thermal noise of MC. I'm not sure about the 40m IMC's actual noise level. The plot in the entry was taken from LLO's MC in 2003.

  6407   Tue Mar 13 19:14:40 2012 kiwamuUpdateLSCNoise estimatino in the REFL33Q as a MICH sensor

A feasibility study of the REFL33Q as a MICH sensor was coarsely performed from the point view of the noise performance.

The answer is that :

  the REFL33Q can be BARELY used as a MICH sensor in the PRMI configuration, but the noise level will be at only sub-nano meter level.

  Tonight I will try to use the REFL33Q to control the MICH DOF to see what happens.

 

(Background)

  I neeeeeeeed a 3f signal which is sensitive enough to hold the Michelson in the PRMI configuration so that I can test the single arm + PRMI configuration.
Based on the data I got in the sensing matrix measurement (#6403) I wanted to see how noises in the REFL33Q look like.
 

(Noise analysis)

  I did a coarse noise analysis for the REFL33Q signal as shown in the attached plot below while making some assumptions as follows.

  •  Optical gain for MICH = 0.8  W/m (#6403)
    • In the plot below, I plotted a unsuppressed MICH motion which had been measured the other day with a different sensor. This is for a comparison.
  •  Shot noise due to DC light on the REFL33 photo diode
    •  With a power of 5.0 mW (#6355)
    • Assume that the responsivity is 0.75 A/W, this DC light creates the shot noise in the photo current at a level of 35 pA/sqrtHz.
    • Then I estimated the contribution of this shot noise in terms of the MICH displacement by calibrating the number with the optical gain and responsivity.
    • It is estimated to be at 60 pm/sqrtHz
  • Dark current
    • I assumed that the dark current is 0.52 mA. (see the wiki)
    • In the same manner as that for the shot noise, the dark current is estimated to be at 20 pm/sqrtHz in terms of the displacement
  • Whitening filter input referred noise
    • I assumed that it is flat with a level of 54 nV/sqrtHz based on a rough measurement by looking at the spectrum of the LSC input signals.
    • The contribution was estimated by applying some gain corrections from the conversion efficiency of the demod board, transimpedance gain, responsivity and the optical gain.
    • This noise is currently the limiting factor over a frequency range from DC to 1 kHz.
  • ADC noise
    • I did the same thing as that for the whitening filter noise.
    • I assumed the noise level is at 6 uV/sqrtHz and it is flat (I know this not true particularly at mHz region the noise becomes bigger by some factors)
    • Then I applied the transfer function of the whitening filter to roll off the noise above 15 Hz.

 NB_REFL33.png

(Some thoughts)

  •   Obviously the limiting noises are that of ADC and the whitening filter.
    • These noise can be easily mitigated by installing an RF amplifier to amplify the RF signals from the REFL33Q RFPD.
    • Therefore this is not the real issue
  • The real issue is that the shot noise is already at a level of 60 pm/sqrtHz, and we can't suppress the MICH motion less than that.
    • In order to decrease it, one possibility is to increase the modulation depth. But it is already at the maximum.
    • If the REFL165 RFPD is healthy, it is supposed to give us a bigger MICH signal. But it didn't look healthy ... (#6403)
  2223   Mon Nov 9 19:09:09 2009 JenneUpdatePEMNoise floor of the Ranger Seismometer

To estimate the noise floor of the Ranger, Rana and I locked the mass on the seismometer, so there will be no (aka minimal) signal from the motion of the ground in the pickup coil.  We should be seeing primarily the noise of the readout electronics.  We also put the Ranger on top of one of the foam lids from the Seismometer Isolation Boxes to further isolate from ground motion (this didn't change the signal noticeably).  

In this plot, Green is the locked-mass-on-foam noise floor, blue is the regular spectra, with the SR560 AC coupled, and the red is the regular seismic spectra with the SR560 DC coupled.  There doesn't seem to be a noticeable difference between blue and red (the spectra were taken at different times of day, with the red taken at night, when we generally expect things to be quieter).  I'm leaving the SR560 DC coupled.  (Rana had found it earlier this afternoon GND coupled....not sure yet why).

Also, we're not sure that the green curve is true readout noise, vs. how much of it is specifically due to the fact that the mass is locked down.  Especially around a few hundred Hz, the green curve is much higher than the other 2, and at a few tens of Hz there is some weird peak action.  However, this will be okay as a first-run noise estimate for the Ranger's noise floor.

The question at hand is: Do we need to redo any of the Ranger's readout electronics (i.e. replace the SR560 with a Pomona Box circuit) to lower the noise floor, or is it okay as-is?

Attachment 1: Ranger_noiseFloor_Spectra.png
Ranger_noiseFloor_Spectra.png
  2890   Thu May 6 18:43:58 2010 ranaUpdatePEMNoise floor of the Ranger Seismometer

I added a noise model of the SR560 to the LISO opamp.lib. This assumes you're using it in G=100, low-noise mode. The voltage noise is correct, but I had to guess on the current noise because I didn't measure it before. Lame.

This can be compared with the noise that we measure when locking it down...

Attachment 1: ranger.pdf
ranger.pdf
  1090   Fri Oct 24 22:30:38 2008 Jenne,ranaUpdatePEMNoise from Guralp Seismometer
Attached is a Power Spectrum of the noise on the Vert1 channel of the Guralp seismometer. The noise is in the several hundreds of nV/rtHz up near 50Hz and higher, but is in the several microV/rtHz range at lower frequencies. Our high frequency noise is almost definitely below the noise of the ADC, but the lower frequencies, where we actually care, it's not as clear.

To Do list:
  • Measure the noise of the ADC - is the Guralp Box lower for all frequencies?
  • Use conversion factors to convert this measured noise into the minimum ground motion that we can measure. Is this at least a factor of 100 lower than our regular ground motion?

** UPDATE: This is actually the noise of the Guralp breakout box, not the Guralp itself. It is the noise measured on the output of the box
with the input shorted. The board is configured to have a gain of 20 (10 from the AD620 and 2x for differential drive). We also measured
directly at the AD620 output and all of this noise comes directly from that chip. If Jenne calculates that this noise is too high we would
have to find a replacement with a better low frequency floor (e.g. LT1012 or LT1007 depending on the Guralps source impedance).
Attachment 1: Vert1_Noise_24Oct2008.png
Vert1_Noise_24Oct2008.png
  3038   Wed Jun 2 18:36:20 2010 valeraDAQCDSNoise generators in LSP

Alex wrote a new code to implement LSP noise generator. The code is based on 64 bit random number generator from Numerical Recipes 3rd ed ch 7.1 (p 343).

Joe made two instances in the LSP model.

The attached plot shows the spectra and coherence of two generators. The incoherence is ~1/Navg - statistically consistent with no coherence.

Attachment 1: noisegenerators.pdf
noisegenerators.pdf
ELOG V3.1.3-