40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 62 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  7507   Mon Oct 8 22:07:46 2012 ranaUpdateSUSDoors on, ready to pump

Quote:

All oplevs need a little realignment, especially ETMY, which had it's lens removed (Rana has a Wall of Shame photo of this, which is why it was removed by him).  Steve will look into this tomorrow, after he starts pumping.

 The shame:

20120921_200637.jpg

There is no situation in which it is OK to install a mount like this. Steve had installed this flaky and shaky mount to optimize the beam size on the OL QPD.

Everyone in the lab should know better. Putting in something like this is just like sabotage - it creates extra noise in our interferometer in a sneaky way and just makes locking harder. All mounts for anything useful (including QPDs) must have highly rigid mounts. 

Use the example from the PSL relayout: use the 3/4" steel mounts and the wide aluminum bases from Newport. No more art projects using home made mounting crap, Steve.

  7250   Wed Aug 22 16:50:09 2012 JenneUpdateLockingDouble integrator in ARM LSC servos

Last week, Rana changed the integrators in the arm LSC servo filters to be double integrators with complex poles. 

Yesterday, I found that using the "timeout" feature of Foton (at filter ON/OFF request, waits for zero crossing, or T seconds, whichever comes first) is useful for turning on the integrators, but bad for turning them off.  When we're locked, the error signal is oscillating around zero, so there is often a zero crossing.  When we lose lock, we want to turn off the filter immediately.  But, as soon as lock is lost, the input signal gets large, and doesn't often cross zero, so the filter waits 8 seconds until actually turning off.  If the arm flashes any time during that 8 sec, we send a big kick to the optics.

An alternative option could be ramping the filter on.  However, since the double integrator has -180deg phase at low frequencies (until the poles at ~5Hz), the transition between no filter (0deg phase) and integrator on could be problematic.  I simulated this, and find that for the very beginning of the ramping process, we would have a problem. 

The filter is defined as:  NoFilter * (1 - R) + Integrator * (R), so for R=0, the integrator is off, and for R=1, the integrator is fully on.  R can be any value [0,1]. 

The first figure is the time series (1 second, 16kHz), ramp goes from 0->1 or 1->0 in 1 second:

 DoubleIntegrator_timeSeries_LowRes.png

 

The second figure is bode plots for selected values of R:

DoubleIntegrator_Bode_vs_Ramp_LowRes.png

As R gets smaller and smaller, the notch goes to lower frequency, and becomes higher Q.  So perhaps ramping is not a good answer here. 

What if we go for single or triple integrator, to get rid of the (+1) + (-1) problem?

  11516   Wed Aug 19 01:45:10 2015 IgnacioUpdateIOODoubly Improved SISO (T240-X) FF of MCL

Today I tried and doubly-improved SISO FF filter on MCL. This filter has a stronger rolloff than the previous SISO filters I have tried. The rolloff most definelty helped towards reducing the ammount of noise being injected into YARM. Below is the usual stuff:

 

Filter:

T240-X (SISO)

 

 

Training data + Predicted FIR and IIR subtraction:

 

Online subtraction results:

MCL
YARM
MCL TRANS
 
 
 

Subtraction performace:

  3583   Fri Sep 17 12:11:42 2010 josephbUpdateCDSDowns update

In doing a re-inventory prior to the IOO chassis installation, I re-discovered we had a missing interface board that goes in an IO chassis.  This board connects the chassis to the computer and lets them talk to each other.  After going to Downs we remembered Alex had taken a possibly broken interface board back to downs for testing. 

Apparently the results of that testing was it was broken.  This was about 2.5 months ago and unfortunately it hadn't been sent back for repairs or a replacement ordered.  Its my fault for not following up on that sooner.

I asked Rolf what the plan for the broken one was.  His response was  they were planning on repairing it, and that he'd have it sent back for repairs today.  My guess the turn around time for that is on the order of 3-4 weeks (based on conversations with Gary), however it could be longer.  This will affect when the last IO chassis (LSC) can be made fully functional.  I did however pickup the 100 foot fiber cable for going between the LSC chassis and the LSC computer (which will be located in 1X3).

As a general piece of information, according to Gary the latest part number for these cards is OSS-SHB-ELB-x4/x8-2.0 and they cost 936 dollars (latest quote).

  5824   Sun Nov 6 16:58:25 2011 ZachUpdateSUSDr. SUS failed--NDS2 problems again

 Dr. SUS failed while trying to get the sensor data. Specifically, it couldn't get ETMY data. This is odd, because in my tribulations last week I ended up having to add the ETMY_SENSOR channels manually into the NDS2 channel files. After doing this, I was able to get ETMY data just fine (though I admitted that we would have problems again as soon as we wanted to update the channel files). I even ran the diagAllSUS code in a sandbox and it pulled data---and generated input matrices---just fine.

The error persists even if I try to get the data manually:

 

>> d = NDS2_GetData({'C1:SUS-ETMY_SENSOR_UL'},t0,10,'mafalda.martian:31200');

Connecting.... authenticate done

Warning: daq_recv_next failed

 

??? Error using ==> NDS2_GetData

Fatal Error getting channel data.

I think Jamie is still waiting for J.Z.'s help with this, but it is probably pointless to keep trying to run this code before NDS2 is working again. Another option is to just use NDS, but I think certain people are opposed to this. 

 

 

  5805   Fri Nov 4 00:25:49 2011 ZachUpdateSUSDr. SUS paths updated--question of human oversight remains
  • I have replaced all instances of /cvs/cds/rtcds with /opt/rtcds in the Dr. SUS code. 
  • We discussed placing a human in charge of whether or not the input matrices get written to the frontend. I am not sure if we reached a definitive conclusion. Currently, the code is set to write the matrices automatically. What to do?
    • If we decide that oversight is necessary, I suggest that we leave the publishing of the results to the elog intact. This way, it will be someone's job to read the weekly Dr. SUS diagnosis on Sunday night (or Monday morning), and run a simple script that writes the matrices. This seems like the most reasonable solution.

I await responses...

  5814   Fri Nov 4 19:30:06 2011 ranaUpdateSUSDr. SUS paths updated--question of human oversight remains

My inclination is to not do the writing of the matrices automatically nor to do the weekly kicks. Its nice to have long locks of the MC, etc.

I suggest just making the kick on Sundays when someone intentionally asks for it (e.g. by pressing a button on Friday). The free-swinging ringdown ought to be a opt-in kind of feature, not opt-out.

  5822   Sat Nov 5 21:19:08 2011 ZachUpdateSUSDr. SUS paths updated--question of human oversight remains

Ok, here's the deal:

  • For the time being, I have written a "doirun" bit into runDrSUS (i.e. it runs if doirun is 1 and doesn't if it's 0). This is a bad way of doing this, so in the end I think we should put a switch on the IFO MEDM and have the script read the value when the cron job is run. If you want it to be an opt-in rather than a toggle, we can have the script write it back to 0 every time. I don't know how to do this yet because I am an MEDM n00b, but I will do it soon.
  • Since we have decided to keep a human in the loop on the writing to the frontend, I have kept the elog results push.
  • I have also edited diagAllSUS.m so that it archives all computed matrices (hierarchy: .../scripts/SUS/peakFit/inMats/(gps_time_of_kick)/inMat(optic_name).mat). There is a 'writematrices' bit in the M-file, currently set to 0.
  • I have written the script 'writeAllInMats' and the accompanying M-file 'writeAllInMats.m'. This allows the user to write whichever set of input matrices he or she desires (syntax: writeAllInMats (gps_time_of_kick)). If no argument is given, then it reads the most recent kick time from 'kickAll.time' and writes the corresponding matrices.

So, here is an example of how this works:

  1. Someone decides to do a diagonalization on a particular weekend, (eventually) clicking a switch in MEDM
  2. Cron runs runDrSUS at 8am that Sunday. This:
    1. Kicks all the optics, lets them swing for 5 hours, then reengages the watchdogs. The kick time is saved in kickAll.time, and an alert is posted to the elog
    2. Runs diagAllSUS, which computes and saves all matrix data. A report of the results is posted to the elog.
  3. On Monday morning---or whenever---someone looks at the entry and decides whether or not to write the files
    1. If the results are good, he or she runs writeAllInMats and the latest matrices are written
    2. If the results are bad, he or she does nothing. The matrices are still archived and can be written at any time in the future.

The code is set to run tomorrow morning. Everything but the writing will be done.

Quote:

My inclination is to not do the writing of the matrices automatically nor to do the weekly kicks. Its nice to have long locks of the MC, etc.

I suggest just making the kick on Sundays when someone intentionally asks for it (e.g. by pressing a button on Friday). The free-swinging ringdown ought to be a opt-in kind of feature, not opt-out.

 

  5301   Thu Aug 25 13:10:42 2011 JenneUpdateSUSDrag wiping

As we have seen in the past, both of the ITMs were more dusty than the ETMs, presumably because we have the vertex open much more often than the ends.  Kiwamu and I wiped all of the optics until we could no longer see any dust particles within a ~1.5 inch diameter area around the center. 

Since we have ITMX out for magnet gluing, I'll probably drag wipe both front and back surfaces before putting it back in the suspension cage.  All of the optics have clear dust on the AR surfaces, but we can't get to that surface while the optics are suspended.  For the ETMs this isn't too big of a deal, but it does concern me a bit for the ITMs and other transmissive optics we have.  I don't think it's bad enough yet though to warrant removing optics from suspensions just to wipe them.

  31   Tue Oct 30 16:55:40 2007 tobinRoutine Drag-wiping perfected
Steve, Tobin

Steve procured an assortment of syringes from the bio storeroom and we practiced drag-wiping the SOS in the flow bench. Using a 50 microliter Hamilton syringe to deliver 16 microliters of methanol seems perfect for drag-wiping the small optics. Drag-wiping in the downward direction seems to work very well, since we can squirt the optic directly in the center, and the (half) piece of kodak lens tissue fits easily between the bottom two earthquake stops.
  2180   Thu Nov 5 16:24:40 2009 JenneUpdateGeneralDrill Press is down for the count

The on/off switch for the drill press is broken.  Replacement parts should be here tomorrow. 

  2218   Mon Nov 9 15:21:37 2009 JenneUpdateGeneralDrill Press is down for the count

Quote:

The on/off switch for the drill press is broken.  Replacement parts should be here tomorrow. 

 Drill press is all better now.  A spare switch is in the top drawer with the drill bits.

  8804   Mon Jul 8 13:45:19 2013 gautamConfigurationendtable upgradeDriver board verification

With the help of an expansion card,  I verified that the + 15V and + 24V from the eurocrate in the slot I've identified for the PZT driver boards are making their way to the board. The slot is at the right-most end of the eurocrate in 1Y4, and the rack door was getting in the way of directly measuring these voltages once I hooked up the driver board to the expansion card. So I just made sure that all the LEDs on the expansion card lit up (indicating that the eurocrate is supplying + 5, + 15 and + 24V), and then used a multimeter to check continuity between the expansion card and the driver board outside of the eurocrate. The circuit only uses + 15V and + 24V, and I checked for continuity at all the IC pins marked with these voltages on the schematic.

Since the whole point of this test was to see if the slot I identified was delivering the right voltages, I think this is sufficient. I will now need to fashion a cable that I can use to connect a DC power supply to the PZT driver boards so that these can be tested further.

The high voltage points (100V DC) remain to be tested.

  9686   Mon Mar 3 21:50:35 2014 JenneUpdateComputer Scripts / ProgramsDropbox installed on Workstations

I have installed Dropbox on the 40m workstations, using the foteee account. 

I put it in /users/Dropbox.

As a side note, I did the install while sitting on Pianosa, but since I put the folder on the mounted hard drive, I think we should be able to use it from any workstation, although I have not yet confirmed this.

  1142   Mon Nov 17 20:47:19 2008 CarynSummaryGeneralDrove MC at 28kHz to excite drum modes
Rana, Alberto and I observed drum mode frequencies at 23.221kHz(MC1), 28.039kHz(MC2), 28.222kHz(MC3) while driving the mode cleaner. We observed no peaks when we didn't drive the mode cleaner. We used the SR785 to send a ~80mV noise signal in the 28-28.2kHz band to the mode cleaner mirrors via 1Y4-MC1,2,3-POSIN. Then we looked at 1Y2-Mode Cleaner-Qmon on the SR785 and saw peaks.
  1158   Sat Nov 22 10:55:51 2008 CarynConfigurationIOODrum modes Lock-In settings changed
I unhooked the MC Demod Board's Qmon signal from the Lock-In. Set the demodulation frequency to 31.11Hz with 1V amplitude, and
put the output into MC_DRUM1. DTT showed a ~30Hz peak. Dataviewer showed signal with amplitude ~20,000.
Otherwise the settings were as Rana had them: Time Constant-100us,24dB/Sensitivity-200us/Low Noise
Want to check if Lock-In frequency drifts.
  2538   Thu Jan 21 11:08:30 2010 kiwamu, steveUpdateVACDry Pump replacement

 This morning I and Steve replaced  the dry fore pump of TP3, which is located under the y-arm.

After replacing it we confirmed vacuum normal condition. The fore line pressure of TP3 went down to 11 mTorr from 750 mTorr

  Attached picture is new pump after setup.

Attachment 1: DSCN0428.JPG
DSCN0428.JPG
  5563   Wed Sep 28 07:46:42 2011 steveUpdateSUSDsub connections at the back of 1X5 are fixed

 

 I'm turning  the sus damping  off for Dsub connection fix at  the back of 1X5 rack

The plan is to install 4-40 jack screws to lock connector positions.

All dewittening(or called coil driver) and wittening D sub connectors are locked with two 4-40 socket head screws

  7916   Fri Jan 18 00:41:34 2013 JenneUpdateLockingDust?

I was thinking tonight about more possible reasons that our PRC sucks, and I wonder if dust on the BS could create the problem.

Historically, Kiwamu and I found a few dust particle scattering centers every time we inspected the test masses before drag wiping. Sometimes, there would be one frustratingly close to the center of the optic. I'm not sure if we ever made note of how many we saw and where they were, except out loud to the assembled crowd.

Anyhow, the BS is the only IFO optic that was not replaced, so I'm not sure how long it has been since it was cleaned. If the PR-flat cavity looks okay and we take out the BS to do a PRM-ITMY cavity, we should inspect the beam splitter.

Also, the PRM could need cleaning, but at least it has been drag wiped within recent memory.

My question is, could a few scattering centers cause the behavior that we are seeing?

 

EDIT:  List o' elogs....

 

Elog 5301 - Some details on dust seen on ITMs and ETMs, Aug 2011.

Elog 4084 - Kiwamu's in-situ drag wiping how-to, with details on some of the dust we saw. Dec 2010.

Elog 3736 - PRM drag wiped before suspension (Oct 2010)

Elog 3111 - June 2010, BS drag wiped.

  7918   Fri Jan 18 12:08:08 2013 KojiUpdateLockingDust?

No

Quote:

My question is, could a few scattering centers cause the behavior that we are seeing?

 

  11238   Thu Apr 23 08:43:40 2015 SteveUpdateElectronicsEG&G InGaAs diodes in stock

RFpds box is moved from RF cabinet E4 to clean cabinet S15

Inventory updated at https://wiki-40m.ligo.caltech.edu/RF_Pd_Inventory

Large Area InGaAs PIN Photodiode -- C30642GH      6 pieces in stock

Product Details
in: Photodiodes

 

Large Area InGaAs PIN Photodiode -- C30642GH -- View Larger Image

Large Area InGaAs PIN Photodiode with a 2,0 mm active diameter chip in TO-5 package with flat glass window

Large area InGaAs PIN photodiode with useful diameter of 2,0 mm in a T0-5 package with a flat glass window. The C30642GH provides high quantum efficiency from 800nm to 1700nm. It features high responsivity, high shunt resistance, low dark current, low capacitance for fast response time and uniformity within 2% across the detector active area.

  3772   Sun Oct 24 19:23:41 2010 ranaConfigurationelogELOG 2.8.0
I stopped the ELOG and restarted us on 2.8.0.

To make sure nothing got lost, I killed the old process, copied over the logbooks/, themes/, and elogd.cfg to the new 2.8.0/ directory before starting the new Daemon.

I encountered the same Administrator bug as Joe had before. I delete all the old Admin passwords to bypass the issue.

To restart the ELOGD on NODUS, you now type '/cvs/cds/caltech/elog/start-elog.csh'.
I also added ELOG to the man pages in /usr/local/man/ on nodus by putting the *.1 files in man1/ and the *.8 files into man8/.
  3775   Mon Oct 25 02:23:47 2010 KojiConfigurationelogELOG 2.8.0
When I push the reply button, the raw html shows up in the edit window and have to use HTML to write the entry.
Does this happen only to me???


Quote:
I stopped the ELOG and restarted us on 2.8.0.

To make sure nothing got lost, I killed the old process, copied over the logbooks/, themes/, and elogd.cfg to the new 2.8.0/ directory before starting the new Daemon.

I encountered the same Administrator bug as Joe had before. I delete all the old Admin passwords to bypass the issue.

To restart the ELOGD on NODUS, you now type '/cvs/cds/caltech/elog/start-elog.csh'.
I also added ELOG to the man pages in /usr/local/man/ on nodus by putting the *.1 files in man1/ and the *.8 files into man8/.
  3780   Mon Oct 25 23:59:37 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

ELOG reverted to 2.7.5 due to editing difficulties

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5

- logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

  3783   Tue Oct 26 07:02:05 2010 AlbertoConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

Quote:

ELOG reverted to 2.7.5 due to editing difficulties

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5

- logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

I think I had the same problem when I switched to 2.75 from 2.65.

Then the problem was FCKeditor.

We should try the solution I put in the elog page of the wiki.

 

  3784   Tue Oct 26 10:50:08 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5 -> ELOG 2.8.0

ELOG restarted with 2.8.0 again.

- moved elog-2.8.0/script dir to elog-2.8.0/script.orig

- copied elog-2.7.5/script to elog-2.8.0/script

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.8.0

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.8.0

- logbooks on 25th and 26th were copied from 2.7.5 to 2.8.0.

 

  10877   Thu Jan 8 03:40:50 2015 ericqUpdateComputer Scripts / ProgramsELOG 3.0

I've installed the very fresh ELOG 3.0, for nothing else than the new built in text editor which has a LATEX capable equation editor built right in. 

Check out this sweet limerick: 

\int_{1}^{\sqrt[3]{3}}t^2 dt\, \textbf{cos}(\frac{3\pi}{9}) = \textbf{ln}(\sqrt[3]{e})

  10878   Thu Jan 8 09:24:40 2015 jamieUpdateComputer Scripts / ProgramsELOG 3.0
Quote:

I've installed the very fresh ELOG 3.0, for nothing else than the new built in text editor which has a LATEX capable equation editor built right in. 

Check out this sweet limerick: 

\int_{1}^{\sqrt[3]{3}}t^2 dt\, \textbf{cos}(\frac{3\pi}{9}) = \textbf{ln}(\sqrt[3]{e})

\int \omega \epsilon \varepsilon \Gamma

  1119   Thu Nov 6 22:07:56 2008 ranaConfigurationComputersELOG compile on Solaris
From the ELOG web pages:

Solaris:

Martin Huber reports that under Solaris 7 the following command line is needed to compile elog:

gcc -L/usr/lib/ -ldl -lresolv -lm -ldl -lnsl -lsocket elogd.c -o elogd

With some combinations of Solaris servers and client-side browsers there have also been problems with ELOG's keep-alive feature. In such a case you need to add the "-k" flag to the elogd command line to turn keep-alives off.
  10405   Fri Aug 15 20:38:17 2014 ericqUpdateGeneralELOG dump

 A few things that I have neglected to ELOG yet:

  • scripts/offsets/LSCoffsets is a new script that uses ezcaservo to set FM offsets of our LSC PDs. It still warns about large changes, and lets you revert. It reads the FM gain to pick the right gain for the ezcaservo call. 

  • MC refl DC was all over the place today, and has recently been "fuzzier" on the wall StripTool than I like. I touched the MC2 pointing a little bit, and the WFS seemed to find a sweet spot where the refl got steady back at around and under 0.5. I then ran "offload WFS" to try and stay there. 

  • Incidentally, the PMC transmission drifted up to 0.81 at some point today. This is weird, since not too long ago, we were not able to reach this level even with careful alignment. This coincided with the MC power being back up to ~17k, and arms locking at around 0.95. 

  • Last week I quickly tried cranking up the x-end green modulation frequency to ~1.3MHz (corresponding to a notch in the PZT AM response), and using a 550k lowpass on the mixer output, instead of a 70k, to try to buy more phase and increase the UGF. It didn't work. I didn't have a way to tune the mixer phase angle, and the mixer output was super noisy, but there were instants where I could convince myself that a mode was briefly locked to the arm... I'm going to do the Right Thing and characterize the loop properly, to figure out how to get at least 10kHz of control bandwidth out of these things. 

  4121   Thu Jan 6 10:47:11 2011 KojiUpdateelogELOG fixed (re: restarted)

Fixed the 40m elog crashing with the threaded display.

This morning I found that Google bot crashed the elog again. I started the investigation and found the threaded mode is fine if we use the recent 10 entries.

I gradually copied the old entries to a temporary elog and found that a deleted elog entry on August 6 had a corrupted remnant in the elog file. This kept crashed the threaded mode.

Once this entry has been eliminated again, the threaded mode got functional.

I hope this eliminates those frequent elog crashing.

Quote:

Google bot  crashed the elog again. Then, I found that Google bot (and I) can crash elogd by trying to show the threaded view.
There looks similar issue reported to the elog forum, the author did not think this is a true bag.

Note: This happens only for the 40m elog. The other elogs (ATF/PSL/TCS/SUS/Cryo) are OK for the threaded view.

Quote:

Did it again. It seemed that Google bot came to the elog and tried to obtain "http://nodus.ligo.caltech.edu:8080/robots.txt". That was the last of the log.
Bot came from the AJW's homepage. Also Google FeedFecther came to the elog.

 

 

  2518   Sun Jan 17 05:22:42 2010 ranaConfigurationComputersELOG script change

With Dave Barker's help, I changed the elog startup script. Instead of running as a Daemon with the -D option,

it now runs in the background with the unix "&". I think that the stdout and stderr are now redirected to a log file called elog.log.

We can 'tail -f' this file to see what its up to and debug any future crashing.

  11002   Wed Feb 11 16:49:41 2015 ranaUpdateelogELOGD restarted

No elog response from outside and no elogd process frownon nodus, so I restarted it using 'start-elog.csh'.

  6594   Wed May 2 21:04:06 2012 DenUpdatePEMEM 172 coherence

I measured coherence between 2 EM 172 microphones in a "quiet room" with SR785

em_coh.png

High-frequency noise (>2k) is SR785 noise - I'm not using any amplifier now, the signal from microphone is sent directly to SR785 and is weak at high frequencies.

  7226   Sat Aug 18 19:29:56 2012 DenUpdatePEMEM 172 microphones noise

I've put EM 172 microphones inside Steve's isolation box to measure their noise. I've attached mics to each other and aligned them using the tape.

At low frequencies (below 1 Hz) the noise is limited by ADC as there is a 10 Hz high-pass filter inside mic readout box.

ADC noise is measured by splitting the signal from 1 mic into 2 ADC channels.

em172.png

  7777   Mon Dec 3 16:37:09 2012 SteveUpdatePEMEM 172 microphones ordered

Quote:

I've put EM 172 microphones inside Steve's isolation box to measure their noise. I've attached mics to each other and aligned them using the tape.

At low frequencies (below 1 Hz) the noise is limited by ADC as there is a 10 Hz high-pass filter inside mic readout box.

ADC noise is measured by splitting the signal from 1 mic into 2 ADC channels.

em172.png

 BT EM172 microphones  are ordered.

  6593   Wed May 2 19:47:20 2012 DenUpdatePEMEM 172 nonlinearities

I've checked new small EM172 microphones for nonlinearities using Koji's Mac Book speakers. EM172 + Mac nonlinearities are presented at the figure

500Hz_noise.png

The Mac's sound frequency was specified to be 500 Hz. Harmonics are seen at 1k, 1.5k, but their amplitude is ~30 times less.

  12344   Wed Jul 27 22:42:00 2016 PrafulUpdateElectronicsEM172 Amplifier

I recreated Den's microphone amplifier circuit on a solderless breadboard to test it and make sure it does what it's supposed to. So far it seems like everything is working- I'll do some testing tomorrow to see what the amplified output is like for some test noises. Here's the circuit diagram that Den made (his elog as well https://nodus.ligo.caltech.edu:8081/40m/6651):

I'm not sure why he set up the circuit the way he did- he has pin 7 grounded and pin 4 going to +12V while in the datasheet for the opamp (http://cds.linear.com/docs/en/datasheet/1677fa.pdf), pin 7 goes to positive voltage and pin 4 goes to negative voltage. There's some other strange things about the circuit that I don't really understand, such as the motivation for using no negative voltage source, but for now I'm going to stick with Den's design and then make some modifications after I have things working and a better understanding of the problem.



Here's my current plan:

-Make sure Den's amplifier works, test it out and make changes if necessary

-Make multiple amplifier circuits on soldering breadboard

-Either make a new amplifier box or reuse Den's old box depending on how many changes I make to the original circuit

-Solder EM172s to BNC connectors, set them up around the floor suspended

-Get the amplifier box hooked up, set up some data channels for the acoustic noise

-Add new acoustic noise tab to the summary pages

 

Den also mentioned that he wanted me to measure the coupling of acoustic noise to DARM.

  12222   Tue Jun 28 17:11:27 2016 PrafulUpdateGeneralEM172 Microphones

Found 60 EM172 microphones. Previous elog with details: 7777.

  12744   Fri Jan 20 17:12:37 2017 SteveUpdatePEMEM172 mic is hooked up in the PSL

Gautam and Steve,

It is hanging in the midle of the PSL enclosure. Wired to 1X1 to get plus and minus 15V through fuse.    It's output is connected to FB c17 input.

GV: C17 corresponds to "MIC 1" in the PEM model. So the output is saved as "C1:PEM-MIC_1_OUT_DQ"

Quote:

I added an EM172 to my soldered circuit and it seems to be working so far. I have taken a spectra using the EM172 in ambient noise in the control room as well as in white noise from Audacity. My computer's speakers are not very good so the white noise results aren't great but this was mainly to confirm that the microphone is actually working.

white_v_ambient.pdf

 

Attachment 1: EM172c.jpg
EM172c.jpg
  12789   Thu Feb 2 17:34:25 2017 ranaUpdatePEMEM172 mic is hooked up in the PSL

I don't know if anyone looked at the time series (not trend) or spectrum of the Microphone after installation, but it looks bad and featureless to me. Is the Microphone broken?

This shows the spectrum from early this morning and again from tonight. You can see that it is bi-stable in its noise properties. This thing is busted; we're now removing it from the PSL so that it doesn' light it self on fire.

http://i.dailymail.co.uk/i/pix/2017/01/23/22/3C6BB70900000578-0-image-a-1_1485211840229.jpg

Attachment 1: MicFail.pdf
MicFail.pdf
  12790   Thu Feb 2 17:43:20 2017 gautamUpdatePEMEM172 mic is hooked up in the PSL

I had noticed something wonky with the microphone, but neglected to elog it. I had tested it after installation by playing a sine wave from my laptop and looking at the signal on the PSL table, it worked fine. But you can see in the attached minute trend plot that the signal characteristics changed abruptly ~half a day after installation, and never quite recovered.\

 

Attachment 1: Mic_broken.png
Mic_broken.png
  1095   Mon Oct 27 14:48:27 2008 YoichiConfigurationPSLEO shutter installed to the reference cavity
I'm now preparing for cavity ring down measurements of the reference cavity.
An EOM for polarization rotation is installed between the two steering mirrors for the reference cavity.
The location is before the polarized beam splitter (used to pick-up the reflected light from the cavity) and
after the half-wave plate. So we should be able to use the PBS as a polarizer.
While setting up the high voltage pulse generator, I realized that we don't have enough cables for it.
It uses special kind of connectors (Kings 1065-N) for HV connections. We need three of those but I could find
only two. I asked Bob to order a new connector.

For the moment, the EOM is left in the beam path of the reference cavity until the connectors arrive (Wed. or Thu. this week)
and the measurements are done.
The EOM distorts the beam and degrades the mode matching to the reference cavity.
I optimized the alignment of the crystal so that the RC transmission is maximum.
Even though, the transmission of the reference cavity is down from 2.8 (without EOM) to 1.7 (with EOM).
I increased the common gain of the FSS from 7dB to 10dB to compensate for this.
The mode clearner locks with this configuration.

If the EOM is really disturbing, one can just take it out.
Since I did not touch the steering mirrors, the alignment to the reference cavity should be recovered immediately.
  6089   Thu Dec 8 14:47:28 2011 JenneUpdateIOOEOM aligned to minimize RAM

Quote:

Monitoring good, but remember that the EOM alignment must be done carefully to minimize the RAM before we can use these trends.

 I temporarily diverted the output of the RAMmon PD to a spectrum analyzer (4195 in Spectrum Analyzer mode), and tweaked the EOM alignment until I minimized the 11 and 55 MHz peaks as much as possible.  It was possible to get each individual peak to disappear into the noise (about -70dBm), but to get both minimized simultaneously I wasn't able to get both down into the noise.  I left the 11MHz at about -55dBm, and the 55MHz at about -60dBm.  If Kiwamu's simulation tells us that one is more significant than the other (55, because we use it for MICH?), then we can decide to favor putting that peak in the noise and sacrifice ~10dB in the other peak. 

When I first plugged the PD into the analyzer, I saw 22MHz and 44MHz (small) peaks, but they went away after the first bit of tweaking.

Before having used the analyzer, I was trying to minimize the demodulated signals via StripTool, but that was a slow process.  The spectrum analyzer was obviously much faster.

The PD has been returned to the regular RAMmon electronics.

Next up: putting in the new demod box that Koji tested last night.

  6043   Tue Nov 29 19:08:53 2011 ZachUpdateRF SystemEOM heater disconnected

I disconnected the heater at ~2:20 UTC, leaving the sensor circuit operational. Don't be fooled by the apparent railing of the heater in the monitor trace below---the heater has been physically disconnected, so there is no current flowing even though the servo is railed (since the error signal is huge with the loop open).

Kiwamu and I also restarted c1sus and locked the MC so that we can get some uncontrolled Stochmon data. I think he is planning to reconnect the heater some hours from now so that we can get yet another controlled data stretch (since the first one was cut short by c1sus's going down).

Screen_shot_2011-11-29_at_7.03.36_PM.png

  14144   Tue Aug 7 23:06:30 2018 KojiUpdatePSLEOM measuement preparation

I was preparing for the aLIGO EOM measuement to be carried out tomorrow afternoon.

I did a few modifications to the PLL setup.

  • The freq mixier in the PLL setup was replaced with ZP3 (level 7) from ZAD-6
  • The PLL gain was reduced from 3.10 to 2.80 to prevent servo oscillation
  • The main PSL marconi is connected to the PLL mixier and providing fixed 200MHz 8dBm.
  • The main PSL modulation is off.

Tomorrow I am going to modulate the EOM with the AUX Marconi via an amplifier (probably)

Automated scripts (AGinit.py and AGmeas.py) are in /users/koji/scripts

I will revert the setup once the measurement is done tomorrow.

  14145   Wed Aug 8 20:56:11 2018 KojiUpdatePSLEOM measuement preparation

Rich and I worked on the EOM measurement. After the measurement, the setup was reverted to the nominal state

  • AUX PLL mixer was restored to ZAD-6
  • The PLL gain was restored to 3.10
  • The main PSL marconi is connected to the freq generator again. Using the beat note, I've confirmed that the modulations are applied on the beam.
  • The PSL HEPA was reduced from 100 to 30.
  6073   Mon Dec 5 19:38:38 2011 JenneUpdateRF SystemEOM mount getting closer....

I have drilled all the holes necessary, and have tapped all but 4 of the holes for the new EOM mount.  The adapter plate is finished and ready to go (including a 10-min iso sonic bath).  The riser that goes between the table and the 9082 mount is drilled but not yet tapped.

  5391   Mon Sep 12 23:54:10 2011 kiwamuUpdateIOOEOM resonant box installed

[Mirko / Kiwamu]

 The resonant box has been installed together with a 3 dB attenuator.

The demodulation phase of the MC lock was readjusted and the MC is now happily locked.

 

(Background)

We needed more modulation depth on each modulation frequency and so for the reason we installed the resonant box to amplify the signal levels.

Since the resonant box isn't impedance matched well, the box creates some amount of the RF reflections (#5339).

In order to reduce somewhat of the RF reflection we decided to put a 3 dB attenuator in between the generation box and the resonant box.

 

(what we did)

 + attached the resonant box directly to the EOM input with a short SMA connector.

 + put stacked black plates underneath the resonant box to support the wight of the box and to relief the strain on the cable between the EOM and the box.

 + put a 3 dB attenuator just after the RF power combiner to reduce RF reflections.

 + readjusted the demodulation phase of the MC lock.

 

(Adjustment of MC demodulation phase)

 The demodulation phase was readjusted by adding more cable length in the local oscillator line.

After some iterations an additional cable length of about 30 cm was inserted to maximize the Q-phase signal.

So for the MC lock we are using the Q signal, which is the same as it had been before.

 

 Before the installation of the resonant box, the amplitude of the MC PDH signal was measured in the demodulation board's monitor pins.

The amplitude was about 500 mV in peak-peak (see the attached pictures of the I-Q projection in an oscilloscope). Then after the installation the amplitude decreased to 400 mV in peak-peak.

Therefore the amplitude of the PDH signal decreased by 20 %, which is not as bad as I expected since the previous measurement indicated 40 % reduction (#2586).

 

Attachment 1: EOM.png
EOM.png
Attachment 2: before.png
before.png
Attachment 3: after.png
after.png
  Draft   Wed Nov 6 20:34:08 2019 KojiUpdateIOOEOM resonant box installed

 

Quote:

[Mirko / Kiwamu]

 The resonant box has been installed together with a 3 dB attenuator.

The demodulation phase of the MC lock was readjusted and the MC is now happily locked.

 

(Background)

We needed more modulation depth on each modulation frequency and so for the reason we installed the resonant box to amplify the signal levels.

Since the resonant box isn't impedance matched well, the box creates some amount of the RF reflections (#5339).

In order to reduce somewhat of the RF reflection we decided to put a 3 dB attenuator in between the generation box and the resonant box.

 

(what we did)

 + attached the resonant box directly to the EOM input with a short SMA connector.

 + put stacked black plates underneath the resonant box to support the wight of the box and to relief the strain on the cable between the EOM and the box.

 + put a 3 dB attenuator just after the RF power combiner to reduce RF reflections.

 + readjusted the demodulation phase of the MC lock.

 

(Adjustment of MC demodulation phase)

 The demodulation phase was readjusted by adding more cable length in the local oscillator line.

After some iterations an additional cable length of about 30 cm was inserted to maximize the Q-phase signal.

So for the MC lock we are using the Q signal, which is the same as it had been before.

 

 Before the installation of the resonant box, the amplitude of the MC PDH signal was measured in the demodulation board's monitor pins.

The amplitude was about 500 mV in peak-peak (see the attached pictures of the I-Q projection in an oscilloscope). Then after the installation the amplitude decreased to 400 mV in peak-peak.

Therefore the amplitude of the PDH signal decreased by 20 %, which is not as bad as I expected since the previous measurement indicated 40 % reduction (#2586).

 

 

ELOG V3.1.3-