40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 85 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  3759   Fri Oct 22 01:23:13 2010 KojiUpdatePSLFound the beat at 1064nm

[Koji / Suresh]

We worked on the 1064 beating a bit more.

- First of all, FSS and FSS SLOW servo were disabled not to have variating Xtal temp for the PSL.

- The PSL Xtal temp (T_PSL) was scanned from 22deg-45deg while we search the Xtal temp (T_Xend) for the Xend laser to have the beat freq well low (f<30MHz).
The pumping current for each laser was I_PSL = 2.101 [A] and I_Xend = 2.000 [A]

For a certain T_PSL, we found multiple T_Xend because the freq of the laser is not a monotonic function of the Xtal temperature. (see the innolight manual).

T_Xend to give us the beating was categorized in the three sets as shown in the figure. The set on "curve2" is the steadiest one. (Use this!)
The trends were quite linear but the slope was slightly off from the unity.

- T_PSL was scanned to see the trend of the PMC output.

The PMC was sometimes locked to the mode with lower transmission (V_PMCT ~ 3.0V).
When T_PSL ~ 31deg we consistently locked the PMC at higer transmission (V_PMCT ~ 5.3V).

At the moment we decided the operating point of T_PSL = 32.25 deg, V_PMCT = 5.34, where we found the beat at T_Xend=38.28deg.

- We cleaned up the PSL table more than how it was. Returned the tools to their original places.
The X-end laser was shut down and was left on the PSL table.

NEXT:
Kiwamu can move the X-end laser to the Xend and realign it.
Then we should be able to see the green beating quite easily.

Attachment 1: 101021_beat.pdf
101021_beat.pdf
  8913   Tue Jul 23 21:32:43 2013 KojiUpdateIOOFound the cause of mysterious MC motion

Thesedays we were continuously annoyed by unELOGGED activities of the interferometer.

MC2 LOCKIN was left on and has continuously injected frequency noise and beam pointing modulation
during all of the comissioning / vent preparation.

C1:SUS-MC2_LOCKIN2_OSC_FREQ was 0.075
C1:SUS-MC2_LOCKIN2_OSC_CLKGAIN was 99

For more than a week ago we noticed that the curve of the MC WFS stripchart suddenly got THICKER.
MC WFS, arm transmission, beam pointing... everything was modulated.
It was not WFS instability, and it was not the cavity mirrors.

Today I made the investigation and finally tracked down the cause of this issue to be on MC2 suspension.
Then it was found that this LOCKIN was ON.

There is no direct record of this lockin in the frame files.
From the recorded channel "C1:IOO-WFS2-YAW_OUT16" (which is the trace on the StripTool chart on the wall)
It was turned on at July 10th, 2:00UTC (July 9th, 7PM PDT)

  8917   Wed Jul 24 14:26:24 2013 ranaUpdateIOOFound the cause of mysterious MC motion

Yes, this was not ELOG'd by me, unfortunately. This was the MC tickler which I described to some people in the control room when I turned it on.

As Koji points out, with the MCL path turned off this injects frequency noise and pointing fluctuations into the MC. With the MCL path back on it would have very small effect. After the pumpdown we can turn it back on and have it disabled after lock is acquired. Unfortunately, our LOCKIN modules don't have a ramp available for the excitation and so this will produce some transients (or perhaps we can ezcastep it for now). Eventually, we will modify this CDS part so that we can ramp the sine wave.

  9046   Wed Aug 21 19:26:19 2013 ranaUpdateIOOFound the cause of mysterious MC motion

Quote:

Yes, this was not ELOG'd by me, unfortunately. This was the MC tickler which I described to some people in the control room when I turned it on.

As Koji points out, with the MCL path turned off this injects frequency noise and pointing fluctuations into the MC. With the MCL path back on it would have very small effect. After the pumpdown we can turn it back on and have it disabled after lock is acquired. Unfortunately, our LOCKIN modules don't have a ramp available for the excitation and so this will produce some transients (or perhaps we can ezcastep it for now). Eventually, we will modify this CDS part so that we can ramp the sine wave.

 I've written a new TICKLE script using the newly found 'cavget' and 'cavput' programs. They are in the standard epics distribution as extension binaries. They allow multichannel read/write as well as ramping, delays, incremental steps, etc. http://www.aps.anl.gov/epics/tech-talk/2012/msg01465.php.

Running from the command line, they seem to work fine, but I've left it OFF for now. I'll switch it into the MC autolocker at some point soon.

  6160   Tue Jan 3 17:25:27 2012 KojiUpdatePSLFound the laser was off

I found the PSL laser has been off for four hours. Nobody seemed to know why.

I just turned it on and it is now providing about 10% lower power compared with one before the shutdown.
Let's keep the eyes on the power if it can recover as the housing gets warm.

  6582   Mon Apr 30 13:00:50 2012 SureshUpdateCDSFrame Builder is down

Frame builder is down.  PRM has tripped its watch dogs.  I have reset the watch dog on PRM and turned on the OPLEV. It has damped down.  Unable to check what happened since FB is not responding.

There was an minor earthquake yesterday morning which people could feel a few blocks away.  It could have caused the the PRM to unlock.

Jamie,Rolf,  is it okay or us to restart the FB?  

  6583   Mon Apr 30 13:58:25 2012 JamieUpdateCDSFrame Builder is down

Quote:

Frame builder is down.  PRM has tripped its watch dogs.  I have reset the watch dog on PRM and turned on the OPLEV. It has damped down.  Unable to check what happened since FB is not responding.

There was an minor earthquake yesterday morning which people could feel a few blocks away.  It could have caused the the PRM to unlock.

Jamie,Rolf,  is it okay or us to restart the FB?  

 If it's down it's alway ok to restart it.  If it doesn't respond or immediately crashes again after restart then it might require some investigation, but it should always be ok to restart it.

  6584   Mon Apr 30 16:56:05 2012 SureshUpdateCDSFrame Builder is down

Quote:

Quote:

Frame builder is down.  PRM has tripped its watch dogs.  I have reset the watch dog on PRM and turned on the OPLEV. It has damped down.  Unable to check what happened since FB is not responding.

There was an minor earthquake yesterday morning which people could feel a few blocks away.  It could have caused the the PRM to unlock.

Jamie,Rolf,  is it okay or us to restart the FB?  

 If it's down it's alway ok to restart it.  If it doesn't respond or immediately crashes again after restart then it might require some investigation, but it should always be ok to restart it.

I tried restarting the fb in two different ways.  Neither of them re-established the connection to dtt or epics.

1) I restarted the fb from the control room console with the 'shutdown' command.  No change.

2) I halted the machine with 'shutdown -h now' and restarted it with the hardware reset button on its front-panel. No change.

The console connected to the fb showed that the network file systems did not load.  Could this have resulted in failure to start several services since it could not find the files which are stored on the network file system?

The fb is otherwise healthy since I am able to ssh into it and browse the directory structure.

  6586   Mon Apr 30 20:43:33 2012 SureshUpdateCDSFrame Builder is down

Quote:

Quote:

Quote:

Frame builder is down.  PRM has tripped its watch dogs.  I have reset the watch dog on PRM and turned on the OPLEV. It has damped down.  Unable to check what happened since FB is not responding.

There was an minor earthquake yesterday morning which people could feel a few blocks away.  It could have caused the the PRM to unlock.

Jamie,Rolf,  is it okay or us to restart the FB?  

 If it's down it's alway ok to restart it.  If it doesn't respond or immediately crashes again after restart then it might require some investigation, but it should always be ok to restart it.

I tried restarting the fb in two different ways.  Neither of them re-established the connection to dtt or epics.

1) I restarted the fb from the control room console with the 'shutdown' command.  No change.

2) I halted the machine with 'shutdown -h now' and restarted it with the hardware reset button on its front-panel. No change.

The console connected to the fb showed that the network file systems did not load.  Could this have resulted in failure to start several services since it could not find the files which are stored on the network file system?

The fb is otherwise healthy since I am able to ssh into it and browse the directory structure.

[Mike, Rana]

The fb is okay.  Rana found that it works on Pianosa, but not on Allegra or Rossa.  It also works on Rosalba, on which Jamie recently installed Ubuntu.

The white fields on the medm  'Status' screen for fb are an unrelated problem.

 

 

  6591   Tue May 1 08:18:50 2012 JamieUpdateCDSFrame Builder is down

Quote:

 

I tried restarting the fb in two different ways.  Neither of them re-established the connection to dtt or epics.

 Please be conscious of what components are doing what.  The problem you were experiencing was not "frame builder down".  It was "dtt not able to connect to frame builder".  Those are potentially completely different things.  If the front end status screens show that the frame builder is fine, then it's probably not the frame builder.

Also "epics" has nothing whatsoever to do with any of this.  That's a completely different set of stuff, unrelated to DTT or the frame builder.

  10600   Mon Oct 13 16:08:49 2014 JenneUpdateCDSFrame builder is mad

I think the daqd process isn't running on the frame builder. 

Daqd_problem_maybe.png

I tried telnetting' to fb's port 8087 (telnet fb 8087) and typing "shutdown", but so far that is hanging and hasn't returned a prompt to me in the last few minutes.  Also, if I do a "ps -ef | grep daqd" in another terminal, it hangs. 

I wasn't sure if this was an ntp problem (although that has been indicated in the past by 1 red block, not 2 red blocks and a white one), so I did "sudo /etc/init.d/ntp-client restart", but that didn't make any change.  I also did an mxstream restart just in case, but that didn't help either. 

I can ssh to the frame builder, but I can't do another telnet (the first one is still hung).  I get an error "telnet: Unable to connect to remote host: Invalid argument"

Thoughts and suggestions are welcome!

  10601   Mon Oct 13 16:57:26 2014 KojiUpdateCDSFrame builder is mad

CPU load seems extremely high. You need to reboot it, I think

controls@fb /proc 0$ cat loadavg
36.85 30.52 22.66 1/163 19295

  10602   Mon Oct 13 17:09:38 2014 ericqUpdateCDSFrame builder is mad

 

This CPU load may have been me deleting some old frame files, to see if that would allow daqd to come back to life. 

Daqd was segfaulting, and behaving in a manner similar to what is described here: (stack exchange link). However, I couldn't kill or revive daqd, so I rebooted the FB. 

Things seem ok for now...

 

  4510   Mon Apr 11 14:17:22 2011 josephb, jamieUpdateCDSFrame wiper script installed

[Joe, Jamie, Alex]

Fixes:

I asked Alex which cron to use (dcron? frcron?).  He promptly did the following:

emerge dcron

rc-update add dcron default

Copied the wiper.pl script from LLO to /opt/rtcds/caltech/c1/target/fb/

At that point, I modified wiper.pl script to reduce to 95% instead of 99.7%.

I added controls to the cron group on fb:

sudo gpasswd -a controls cron

I then added the wiper.pl to the crontab as the following line using crontab -e.

0 6 * * *       /opt/rtcds/caltech/c1/target/fb/wiper.pl --delete &> /opt/rtcds/caltech/c1/target/fb/wiper.log

Notes:

Note, placing backups on the /frames raid array will break this script, because it compares the amount in the /frames/full/, /frames/trends/minutes, and /frames/trends/seconds to the total capacity. 

Apparently, we had backups from September 27th, 2010 and March 22nd, 2011.  These would have broken the script in any case. 

We are currently removing these backups, as they are redundant data, and we have rsync'd backups of the frames and trends.  We should now have approximately twice the lookback of full frames.

  4109   Wed Jan 5 00:23:30 2011 ranaSummaryDAQFrameBuilder fails in a new way

Since Leo was trying to demo his LIGO Data Listener code, he noticed that there was and NDS2 issue. The NDS2 guy (JZ) noticed that the FrameBuilder had an issue.

We investigated. At 4PM on Dec 31, the GPS timestamp of the frame file names started to be recorded wrong. In fact, it started to give it a file name matching the correct time from 1 year in the past.

So that's our version of the Y2011 bug. Here's the 'ls' of /frames/full:

drwxr-xr-x 2 controls controls 252K Dec 26 03:59 9773
drwxr-xr-x 2 controls controls 260K Dec 27 07:46 9774
drwxr-xr-x 2 controls controls 256K Dec 28 11:33 9775
drwxr-xr-x 2 controls controls 252K Dec 29 15:19 9776
drwxr-xr-x 2 controls controls 244K Dec 30 19:06 9777
drwxr-xr-x 2 controls controls 188K Dec 31 16:00 9778
drwxr-xr-x 2 controls controls 148K Jan  1 08:53 9463
drwxr-xr-x 2 controls controls 260K Jan  2 12:39 9464
drwxr-xr-x 2 controls controls 252K Jan  3 16:26 9465
drwxr-xr-x 2 controls controls 248K Jan  4 20:13 9466
drwxr-xr-x 2 controls controls  36K Jan  5 00:22 9467
controls@fb /frames/full $

The culprit is the directory who's name starts out as 9463 whereas it should be 9779.

 

  4112   Wed Jan 5 16:00:11 2011 rana, alexSummaryDAQFrameBuilder fails in a new way

Email from Alex:

Turned out to be the lack of current year information in the IRIG-B signal
received by the Symmetricom GPS card in the frame builder machine caused
this. I have added a constant in daqdrc to bring the seconds forward:

controls@fb /opt/rtcds/caltech/c1/target/
fb $ grep symm daqdrc
#set symm_gps_offset=-1;
set symm_gps_offset=31536001;

Hopefully we will be upgrading to the newer timing system at the 40M this
year, so this will not happen again next year.


 

Doing an 'ls -lrt' in /frames/full/ now shows that the names are correct:

drwxr-xr-x 2 controls controls 249856 Dec 30 19:06 9777
drwxr-xr-x 2 controls controls 192512 Dec 31 16:00 9778
drwxr-xr-x 2 controls controls 151552 Jan  1 08:53 9463
drwxr-xr-x 2 controls controls 266240 Jan  2 12:39 9464
drwxr-xr-x 2 controls controls 258048 Jan  3 16:26 9465
drwxr-xr-x 2 controls controls 253952 Jan  4 20:13 9466
drwxr-xr-x 2 controls controls 151552 Jan  5 13:54 9467
drwxr-xr-x 2 controls controls  12288 Jan  5 15:57 9783

  4115   Wed Jan 5 22:14:41 2011 ranaSummaryDAQFrameBuilder fails in a new way

Just a proof that the DAQ is working - ran DTT on nodus from 3 hours ago.

Attachment 1: Screen_shot_2011-01-05_at_10.13.21_PM.png
Screen_shot_2011-01-05_at_10.13.21_PM.png
  14356   Thu Dec 13 22:56:28 2018 gautamUpdateCDSFrames

[koji, gautam]

We looked into the /frames situation a bit tonight. Here is a summary:

  1. We have already lost some second trend data since the new FB has been running from ~August 2017.
  2. The minute trend data is still safe from that period, we believe.
  3. The Jetstor has ~2TB of trend data in the /frames/trend folder.
    • This is a combination of "second", "minute_raw" and "minute".
    • It is not clear to us what the distinction is between "minute_raw" and "minute", except that the latter seems to go back farther in time than the former.
    • Even so, the minute trend folder from October 2011 is empty - how did we manage to get the long term trend data?? From the folder volumes, it appears that the oldest available trend data is from ~July 24 2015.

Plan of action:

  1. The wiper script needs to be tweaked a bit to allow more storage for the minute trends (which we presumably want to keep for long term).
  2. We need to clear up some space on FB1 to transfer the old trend data from Jetstor to FB1.
  3. We need to revive the data backup via LDAS. Also summary pages.

BTW - the last chiara (shared drive) backup was October 16 6 am. dmesg showed a bunch of errors, Koji is now running fsck in a tmux session on chiara, let's see if that repairs the errors. We missed the opportunity to swap in the 4TB backup disk, so we will do this at the next opportunity.

  4319   Thu Feb 17 23:41:46 2011 ranaFrogsDAQFrames Directory got the wrong name: Data unreachable

DTT stopped working for recent data. An 'ls' in the frames/full/ directory reveals:

drwxr-xr-x 2 controls controls 258048 Feb  3 12:26 9807
drwxr-xr-x 2 controls controls 258048 Feb  4 16:13 9808
drwxr-xr-x 2 controls controls 262144 Feb  5 19:59 9809
drwxr-xr-x 2 controls controls 258048 Feb  6 23:46 9810
drwxr-xr-x 2 controls controls 258048 Feb  8 03:33 9811
drwxr-xr-x 2 controls controls 262144 Feb  9 07:19 9812
drwxr-xr-x 2 controls controls 253952 Feb 10 11:06 9813
drwxr-xr-x 2 controls controls 266240 Feb 11 14:53 9814
drwxr-xr-x 2 controls controls 266240 Feb 12 18:39 9815
drwxr-xr-x 2 controls controls 266240 Feb 13 22:26 9816
drwxr-xr-x 2 controls controls 262144 Feb 15 02:13 9817
drwxr-xr-x 2 controls controls 253952 Feb 16 05:59 9818
drwxr-xr-x 2 controls controls 241664 Feb 17 09:46 9819
drwxr-xr-x 2 controls controls  28672 Feb 17 12:22 9820
drwxr-xr-x 2 controls controls  32768 Feb 17 15:06 6663
drwxr-xr-x 2 controls controls  73728 Feb 17 23:39 6664
controls@fb /frames/full $ date
Thu Feb 17 23:39:27 PST 2011

  13356   Wed Oct 4 17:18:15 2017 gautamUpdateCDSFree DAC channels in c1lsc

There are at least 5 free DAC channels (4 if you discount the one channel from these that I am hijacking) available in the 1Y2 electronics rack.

Jamie's nice wiring diagram shows the topology - the actual DAC card sits in 1Y3 inside the c1lsc expansion chassis (while the c1lsc frontend itself is in 1X4). The output of the DAC goes via SCSI to an interface box (D080303) and then to some dewhitening/AI boards (D000316). There are a total of 16 DAC channels available, out of which 8 are used for the TTs, 2 are used for the DAFI model, and one is labeleld "From c1ioo 1X2" (I don't know what this one is for). So I'm going to use some of these channels for measuring the coupling of oscillator noise and intensity noise to MICH in the DRMI lock.

The de-whitening/AI board seems to be old - it has 2x 800Hz Butterworth LPFs and no notch for the clock frequency, but maybe this doesn't matter for the tests I have in mind. The AI board available on 1X2 is more modern but routing the DAC channels from 1Y2 to it is going to be some work.

I'm going to add my testpoint to c1daf given that it seems to be the least critical model on c1lsc.

EDIT: testpoints added to c1daf don't show up in the list of available channels - there was some issue with this model while we were getting the new RTCDS going. So I'm moving my temporary testpoint to c1cal instead.

  9159   Wed Sep 25 17:07:08 2013 ranaFrogsTreasureFree Green Mango Juice in fridge

aam_pana_recipe.jpg

its an acquired taste, but its a must since we're sending an interferometer to India

  5344   Tue Sep 6 17:43:01 2011 SureshUpdateIOOFree Swing ITMY started

Free swing of ITMY started at

Tue Sep  6 17:41:43 PDT 2011

 

  5347   Tue Sep 6 17:56:53 2011 JenneUpdateIOOFree Swing ITMY started

Quote:

Free swing of ITMY started at

Tue Sep  6 17:41:43 PDT 2011

 

 I think Kiwamu accidentally restarted this kick at 17:48:02 PDT.

  2391   Thu Dec 10 17:13:36 2009 kiwamuUpdateSUSFree swiging spectra under the atmospheric pressure

The free swinging spectra of ITMs, ETMs, BS, PRM and SRM were measured last night in order to make sure that nothing wrong have happened by the wiping.

I think there are nothing wrong with ITMs, ETMs, BS, PRM and SRM successfully.

For the comparison, Yoichi's figure in his elog entry of Aug.7 2008 is good, but in his figure somehow PRM spectrum doesn't look correct.

Anyway, compared with his past data, there are no significant changes in the spectra. For PRM which has no counterpart to compare with, its shape of spectra looks similar to any other spectra. So I think PRM is also OK. The measured spectra are attached below.

Indeed the current data are still showing smaller peak height for their pitch and yaw modes (roughly factor of 10 ).
 
Attachment 1: summary_freeswing.pdf
summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf
  12523   Thu Sep 29 16:19:29 2016 LydiaUpdateSUSFree swing eigenmodes

[Lydia, Teng]

Motivated by the strange pitch/yaw coupling behavior we ran into while doing diagonalization, we looked at the oplev pitch and yaw free swing spectra for all 4 test masses (see attachment 1). We saw the same behavior there: At the peak frequencies for the angular degress of freedom, the oplevs saw significant contributions from both pitch and yaw. We also examined the phase between pitch and yaw at these peaks and found that consistently, pitch and yaw were in phase at one of the resonance frequencies and out of phase at the other (ignoring the pos and side peaks). 

This corresponds physically to angular motion about some axis that is diagonal, ie not perfectly vertical or horizontal. If we trust the oplev calibration, and Eric says that we do, then the angle of this axis of rotation with the horizontal (pitch axis) is

 \theta = \arctan \frac{Y\left ( f_{peak} \right )}{P\left ( f_{peak} \right )}  

Where Y and P are yaw and pitch ASD values. This will always give an angle between 0 and 90 degrees; which quadrant the axis of rotation occupies can be dermined by looking at the phase between pitch and yaw at the same frequencies. 0 phase means that the axis of rotation lies somewhere less than 90 degrees counterclockwise from the horizontal as viewed from the AR face of the optic, and a phase of 180 degrees means the axis is clockwise from horizontal (see attachment 2). Qualitatively, these features show up the same way for segments of data taken at different times. In order to get some quantitative sense of the error in these angles, we found them using spectrogram values with a bandwidth of 0.02 Hz averaged over 4000 seconds. 

Results (all numbers in degrees unless otherwise specified):

ITMY
peak 1 ( 0.692  Hz):
mean: 24.991
std: 1.23576
ptich/yaw phase: -179.181
peak 2 ( 0.736  Hz):
mean: 21.7593
std: 0.575193
pitch/yaw phase: 0.0123677

 

ITMX
peak 1 ( 0.502  Hz):
mean: 17.4542
std: 0.745867
ptich/yaw phase: -179.471
peak 2 ( 0.688  Hz):
mean: 74.822
std: 0.455678
pitch/yaw phase: -0.43991

 

ETMX
peak 1 ( 0.73  Hz):
mean: 43.1952
std: 1.54336
ptich/yaw phase: -0.227034
peak 2 ( 0.85  Hz):
mean: 60.7117
std: 0.29474
pitch/yaw phase: -179.856

ETMY
peak 1 ( 0.724  Hz):
mean: 78.2868
std: 2.18966
ptich/yaw phase: 6.03312
peak 2 ( 0.844  Hz):
mean: 26.0415
std: 2.10249
pitch/yaw phase: -176.838

ETMY and ITMX both show a more significant (~4x) contribution from pitch on one peak, and from yaw on the other. This is reflected in the fact that they each have one angle somewhat close to 0 (below 30 degrees) and one close to 90 (above 60 degrees). The other two test masses don't follow this rule, meaning that the 2 angular frequency peaks do not correspond to pitch and yaw straightforwardly. 

Also, besides ITMX, the axes of rotation are at least several degrees away from being perpendicular to each other. 

 

Attachment 1: 05.png
05.png
Attachment 2: SUS_eigenmodes.png
SUS_eigenmodes.png
  836   Thu Aug 14 19:08:14 2008 YoichiConfigurationSUSFree swing measurement going on
I started free swinging spectra measurement of all the suspensions now Aug 14 19:05 (PDT).
The watch dogs are all shutdown. Please do not turn them back on until tomorrow morning.
  9113   Thu Sep 5 15:18:41 2013 JenneUpdateLSCFree swinging DRMI power buildups

I have the DRMI free swinging right now, since it's not really locking.  Looking at these time series in the attached pdf, particularly around time=1.15, it would be super handy to trigger the SRCL degree of freedom on AS110 after the PRMI is triggered on POP22.

Attachment 1: DRMI_free_swing_power_buildups.pdf
DRMI_free_swing_power_buildups.pdf
  807   Thu Aug 7 10:07:13 2008 YoichiUpdateSUSFree swinging OSEM spectra
Looks like there are more extra peaks in the SRM than other optics.
Maybe because it is closer to the door ?
Attachment 1: FreeSwingSpectra.pdf
FreeSwingSpectra.pdf FreeSwingSpectra.pdf FreeSwingSpectra.pdf FreeSwingSpectra.pdf FreeSwingSpectra.pdf FreeSwingSpectra.pdf FreeSwingSpectra.pdf FreeSwingSpectra.pdf
  808   Thu Aug 7 10:27:59 2008 ranaUpdateSUSFree swinging OSEM spectra
Sometimes we see extra peaks in the OSEM spectra coming from a beat between the regular eigenmodes.
This probably comes from the OSEM shadow sensor not being entirely linear - the nonlinearity is
greatly increased if the magnet is not perfectly centered in the LED beam. So the beats are
probably there at some level in all of them; usually below the noise.
  2363   Tue Dec 8 03:53:49 2009 kiwamuUpdateSUSFree swinging spectra of ETMX

In this night, I checked the free swinging spectra of ETMX to make sure nothing wrong with ETMX by the wiping.

Compared with the past (Aug.6 2008), the spectra of ETMX doesn't show significant change.

Successfully the wiping activity didn't change its configuration so much and didn't bring bad situations.

(bad situation means for example, the suspended components hit some others).

 

 The spectra of ETMX by DTT are attached. Also you can see the past spectra in Yoichi's entry.

Yoichi's data was taken during the air-pressure condition, so it's good for comparing.

Actually I compared those data by my eyes, because I could not get the past raw data somehow.

The resonant frequencies and their typical height changed a little bit, but I think those are not significant.

NOTE: In the figure, pitch and yaw modes (~0.57Hz and ~0.58Hz) look like having a smaller Q-factor than the past.

 

Attachment 1: ETMX_air.png
ETMX_air.png
  7078   Thu Aug 2 11:09:52 2012 EricSummaryLSCFree-Swinging Michelson Measurements

To take the free swinging Michelson measurements for the interferometer calibration Jamie aligned the beam splitter with ITMX and ITMY. I recorded the GPS time (1027827100 and for several hundred seconds later) when the Michelson was aligned in order to look at the correct data. I then copied the python script nds-test.py from Jamie, and modified it to take and plot data from C1:LSC-AS55_Q_ERR_DQ offline. I used dataviewer to verify that C1:LSC-AS55_Q_ERR_DQ and C1:LSC-AS55_Q_ERR were recording the same signal, and to check that I was taking the correct data with NDS. Taking data online worked as well, but it was easier to use a time when the Michelson was known to be free-swinging and take data offline. Attached is some sample data while free-swinging, with time in GPS time.

Attachment 1: free_swing_MICH.png
free_swing_MICH.png
  5266   Fri Aug 19 01:15:22 2011 SureshUpdateSUSFreeSwing all optics

I ran "freeswing all" at Fri Aug 19 01:09:28 PDT 2011 (997776583)  and "opticshutdown"  as well.

 

  11640   Thu Sep 24 17:01:37 2015 ericqUpdateComputer Scripts / ProgramsFreeing up some space on /cvs/cds

I noticed that Chiara's backup HD (which has a capacity of 1.8TB, vs the main drives 2TB) was near to getting full, meaning that we would soon be without a local backup. 

I freed up ~200GB of space by compressing the autoburt snapshots from 2012, 2013, 2014. Nothing is deleted, I've just compressed text files into archives, so we can still dig out the data whenever we want.

  5353   Wed Sep 7 00:44:51 2011 JenneUpdateSUSFreeswing all

I just started a freeswing all, as a final check before we pump:


Wed Sep  7 00:43:21 PDT 2011
999416616

Wed Sep  7 00:43:32 PDT 2011
WATCHDOGS WILL BE RESET 5 HOURS AFTER THIS TIME
sleeping for 5 hours...

Jamie: Please do a quickie analysis (at least for the ITMs) before helping Steve with the heavy doors.

I closed the PSL shutter.

Both ITM chambers were checked for tools, so there should be nothing left to do but put the heavy doors on, and begin pumping.

  16872   Tue May 24 15:21:13 2022 AnchalUpdateBHDFreeswing tests of new SOS started

I modified the script freeSwing.py to use damping loop output switches to free the optic instead of watchdog or coil output filters. This ensures that the free swing test is being done at the nominal position of the optic. I started tests for LO1, LO2, As2, As4, PR2, PR3, and SR2 in a tmux session names freeSwing on rossa.


Note: LO2 face OSEMs are hardly sensitive to any motion right now due to excessive pitch offset required for LO beam. We should relieve this offset to LO1 and rerun this test later.

  15711   Sat Dec 5 20:44:35 2020 gautamUpdateASCFreq Gen Box re-installed

This work is now complete. The box was characterized and re-installed in 1X2. I am able to (briefly) lock the IMC and see PDH fringes in POX and POY so the lowest order checks pass.

Even though I did not deliberately change anything in the 29.5 MHz path, and I confirmed that the level at the output is the expected 13 dBm, I had to lower then IN1 gain of the IMC servo by 2dB to have a stable lock - should confirm if this is indeed due to higher optical gain at the IMC error point, or some electrical funkiness. I'm not delving into a detailed loop characterization today - but since my work involved all elements in the RF modulation chain, some detailed characterization of all the locking loops should be done - I will do this in the coming week.

After tweaking the servo gains for the POX/POY loops, I am able to realize the single arm locks as well (though I haven't dont the characterization of the loops yet).

I'm leaving the PSL shutter open, and allowing the IMC autolocker to run. The WFS loops remain disabled for now until I have a chance to check the RF path as well.


Unrelated to this work: Koji's swapping back of the backplane cards seems to have fixed the WFS2 issue - I now see the expected DC readbacks. I didn't check the RF readbacks tonight.

Update 7 Dec 2020 1 pm: A ZHL-2 with heat sink attached and a 11.06 MHz Wenzel source were removed from the box as part of this work (the former was no longer required and the latter wasn't being used at all). They have been stored in the RF electronics cabinet along the east arm.

Attachment 1: IFOverview.png
IFOverview.png
Attachment 2: IMG_0004.jpg
IMG_0004.jpg
Attachment 3: IMG_9007.jpg
IMG_9007.jpg
Attachment 4: IMG_0003.jpg
IMG_0003.jpg
Attachment 5: schematicLayout.pdf
schematicLayout.pdf
Attachment 6: EOMpath_postMod.pdf
EOMpath_postMod.pdf
  15710   Fri Dec 4 22:41:56 2020 gautamUpdateASCFreq Gen Box revamp

This turned out to be a much more involved project than I expected. The layout is complete now, but I found several potentially damaged sections of cabling (the stiff cables don't have proper strain relief near the connectors). I will make fresh cables tomorrow before re-installing the unit in the rack. Several changes have been made to the layout so I will post more complete details after characterization and testing.

I was poring over minicircuits datasheets today, and I learned that the minicircuits bandpass filters (SBP10.7 and SBP60) are not bi-directional! The datasheet clearly indicates that the Male SMA connector is the input and the Female SMA connector is the output. Almost all the filters were installed the other way around 😱 . I'll install them the right way around now.

  4239   Wed Feb 2 10:44:26 2011 KojiSummaryGreen LockingFreq fluctuation measured by the freq divider and Rana's analog PFD

The freq fluctuation of the beat note has been measured with the following condition

  • The IR beam only locked to the MC. The green beam locked to the arm
  • Both of the IR and green locked to the x-arm

Calibration
- The output of the freq divider is already calibrated to have the unit of MHz.

- The transfer function between the analog PFD channel and the digital PFD output was measured to be -23dB = 0.7.
  The gain of the XARM-FINE channel was changed to 0.7 such that the output is calibrated in MHz.

Results

- I have not checked the analog noise level of the analog PFD path. We may need more whitening gain (by icreasing the gain of SR560).

- The analog PFD is always better than the digital PFD above 20Hz.

- Both the digital and analog PFD showed good agreement below 20Hz.
  Note the measurement was not simultaneous.

- When the arm is locked with the ETMX being actuated , the fluctuation of the arm length must be stabilized by a huge factor
(~10^5 according to Kiwamu's entry) However, we only could see the stabilization factor of 30.

As this residual is the difference of the freq noise felt by the IR and the green,
this is a real issue to be tackled.

- The RMS fluctuations of the arm with and without the IR beam being locked are 2MHz and 0.1MHz,
which correcponds to the arm length motion of 250nm and 13nm, respectively.
Ed: I had to use 532nm in stead of 1064nm. The correct numbers are 130nm and 7nm.

- Without the IR locked, The typical peak-to-peak fluctuation of the beat freq was 10MHz.

Attachment 1: 110201_green_freq_fluctuation.pdf
110201_green_freq_fluctuation.pdf
  4240   Wed Feb 2 12:55:34 2011 KojiSummaryGreen LockingFreq fluctuation measured by the freq divider and Rana's analog PFD

I found that some flakiness of the beat signals comes from the RF components for the beat detection.
They are touching the racks in an indefinite way. If we move the components the output of the analog PFD
goes crazy.

Once Kiwamu is back I will ask him to clean up all of the green setting in an appropriate way.

 

  3565   Mon Sep 13 11:40:50 2010 AlbertoUpdateElectronicsFrequency Box Documentation Added to the SVN

I uploaded all the material about the RF frequency Generation Box into the SVN under the path:

https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/RFsystem/frequencyGenerationBox/

I structured the directory as shown in this tree:

freqBoxSVNdierctoryStructure.png

I'm quickly describing in a section of the Rf system upgrade document with LIGO # T1000461.

  3572   Tue Sep 14 18:07:41 2010 AlbertoUpdateElectronicsFrequency Box Documentation Added to the SVN

I completed a LIGO document describing design, construction and characterization of the RF System for the 40m upgrade.

It is available on the SVN under https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/RFsystem/RFsystemDocument/

It can also be found on the 40m wiki (http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/RF_System#preview), and DCC under the number T1000461.

  10008   Mon Jun 9 09:51:11 2014 Sai AkhilUpdateElectronicsFrequency Error Measurement of UFC-6000 RF Frequency Counter

 Motivation: 

 
To test the precision of Mini-Circuits Model UFC-6000 RF Frequency Counter which will be used for recording the beat note for the Frequency Offset Locking Loop(FOLL).
 
 
Setup:
 
Mini Circuits RF Frequency Counter Model UFC-6000 has three I/O ports:
1)REF IN,2)USB INTERFACE,3)RF IN.
The USB INTERFACE is connected to the PC(Windows/Linux) through a USB cable.
The test RF input from an SRS Function Generator(Model DS 345 with tested precision up to 1mHz)is fed in through RF IN using an SMA cable with an SMA-BNC adaptor to connect to the Function Generator.
The REF IN is open since we want to test the counter.
 
 
What I did:
 
1. First interfaced the counter with the PC with windows OS.
 
2. Installed the user friendly GUI on my Laptop so as to record the data from the counter into a .txt file.
 
3. Gave an RF input through the function generator and recorded the response of the counter for different frequencies ranging from 1MHz to 30MHz.
 
4.Analyzed the collected data by plotting the histograms(attached) in Matlab(script attached in .zip file)
 

What was Expected:
 
The measurement statistics of the instrument would give knowledge about the error and tolerance in the measurement which will be helpful to negotiate the error when the counter is being used in the setup. 
 
 
Results:
 
The obtained plots(for sampling time of 1s) are attached in a figure.
The measurement error of the frequency counter for 1s sampling time is:
 
data file     Frequency       Mean in MHz            Standard Error(+/-)in Hz    
 1MH.txt            1MHz            0.999999846             0.0109
 5MHz.txt          5MHz            5.000000293             0.0134
 10MHz.txt       10MHz         10.00000148              0.0108
 15MHz.txt       15MHz         15.0000018                0.0072
 20MHz.txt       20MHz         20.00000053              0.0259
 30MHz.txt       30MHz         30.00000146              0.0230
 
The measurement error of the UFC-6000 RF Frequency Counter is in the order of 0.01-0.02 Hz. This error varies at different frequencies as inferred from the table.
The error for different sampling times of the FC are also plotted.
 
Plan:
 
To complete interfacing the counter with the Raspberry-pi.
Make this Frequency Counter talk to EPICS through slow channels.
 
 
 
 
 
 
Attachment 1: Data_and_Script_Files.zip
Attachment 2: Error_Measurement_FC.pdf
Error_Measurement_FC.pdf
Attachment 3: Error_freq.jpg
Error_freq.jpg
  3552   Thu Sep 9 12:02:03 2010 AlbertoUpdateElectronicsFrequency Generation Box - Amplitude Noise Measurements

I measured the amplitude noise of the source outputs and the EOM outputs of the Frequency Generation box.

the setup I used is shown in this diagram:

FreqBoxAmplitudeNoiseMeasurementSetup.png

(NB It's important that the cables from the splitter to the RF and LO inputs of the mixers are the same length).

The results of the measurements are shown in the following plot:

 FreqBoxAmplitudeNoise_BusbyBox_AllChannels.png

Considerations:

1) both Crystals (29.5MHz and 11MHz) have the same noise

2) the 55MHz source's noise is bigger than the 11 MHz (~2x): the frequency multiplication and amplification that happen before it, add extra noise

3) the noise at EOM outputs is ~2x bigger than that of the relative sources

 

When I have the chance, I'll plot the results of my calculations of expected noise and compare them with the measurements.

  3530   Tue Sep 7 08:56:00 2010 AlbertoUpdateElectronicsFrequency Generation Box Assembly - Phase Noise Measurements

Here are the results of my phase noise measurements on the 7 outputs of the Frequency Generation Box. (BIN=95L applied by DTT). See attached pdf for a higher definition picture.

2010-09-03_FreqBoxPhaseNoise_AllOutputsComparison_smooth.png

The plot shows that the phase noise of the 11 MHz outputs (Source, EOM modulation signal, Demodulation signal) is as low as that of the Marconi. The Marconi is limiting my measurement's resolution.

The mode cleaner signal's oscillator (29.5 MHz output, blue trace) is higher than the 11MHz above 1KHz.

The 55MHz signals have all the same phase noise (traces overlapped), and that is higher than the 11 MHz ones from about 100Hz up. i don't know what's going on.

I need to use the spare 11MHz Wenzel crsytal to have a better reference source for the measurement.

Attachment 2: 2010-09-03_FreqBoxPhaseNoise_AllOutputsComparison_smooth.pdf
2010-09-03_FreqBoxPhaseNoise_AllOutputsComparison_smooth.pdf
  3450   Fri Aug 20 16:41:43 2010 AlbertoUpdateElectronicsFrequency Generation Box Assembly Completed

I finished assembling the frequency generation unit for the upgrade. I tested it through to check that the power levels are as expected at the various connection (see attached png, showing in black the design power values, and in red the measured ones).

Because of some modifications made on the design along the construction, I have to recalculate the SNR along the lines.

I can now start to measure phase noise and distortion harmonics.

A document with a description of the design and the results of the characterization measurements will be available in the end.

 

Attachment 1: RFplan_6_measured_powers.png
RFplan_6_measured_powers.png
Attachment 2: DSC_2409.JPG
DSC_2409.JPG
Attachment 3: DSC_2413.JPG
DSC_2413.JPG
Attachment 4: DSC_2414.JPG
DSC_2414.JPG
Attachment 5: DSC_2415.JPG
DSC_2415.JPG
Attachment 6: DSC_2417.JPG
DSC_2417.JPG
Attachment 7: DSC_2419.JPG
DSC_2419.JPG
  468   Thu May 8 01:07:24 2008 ranaSummaryLSCFrequency Noise test: MC Trans Backscatter
There is a wandering hump in the MC_F spectrum. It can move around on the time
scale of seconds between 40 and 200 Hz. It has an amplitude ~5-50x above the background spectrum. This seems new; I don't remember it
from a year ago. It is there in the IFO unlocked as well as the IFO locked as well as the locked + CM mode.

Tapping the AS table and/or the PSL table enclosures produces a broadband increase in the MC_F spectrum but doesn't
selectively effect the hump.

We thought it might be backscatter from the MC TRANS path and so we stuck in one of Steve's cool black glass V's into
this space. No effect. We should design a black glass V dump which we can replicate in large quantities for us and for
the sites. Something like the one on the LSC PDs, but with a 1 sq. inch opening area and a 2 inch depth.


We have also done this on the MC2 - TRANS beam before. No noise reduced there either.

The noise hump is appearing in MC_F but not in CARM_IN1 (after the CM handoff) so it seems like the MC has enough gain
to squash it. This also exonerates the MC REFL path since anything there would not be effected by the MC servo gain and
so would be visible in CARM.

My best guess is that there is something really, really scattery on the PSL table. But for now it looks like this is not a
big factor in the locking
issues.
  10760   Sun Dec 7 13:11:57 2014 manasaSummaryGeneralFrequency Offset Locking - To Do List

Attached is the timeline for Frequency Offset Locking related activities. All activities will be done mostly in morning and early afternoon hours.

Attachment 1: FOLtodolist.pdf
FOLtodolist.pdf
  10791   Fri Dec 12 14:38:39 2014 manasaSummaryGeneralFrequency Offset Locking - To Do List (Revised)

Unfortunately the order placed for beam samplers last week did not go through. These will be used at the X and Y end tables to dump the unwanted light appropriately. Since they will not be here until Tuesday, I revised the timeline for FOL related activities accordingly.

Attachment 1: FOLtodolist.pdf
FOLtodolist.pdf
  10779   Thu Dec 11 12:39:31 2014 diegoUpdateComputer Scripts / ProgramsFrequency Offset Locking scripts status

 I finished the polishing in the scripts/FOL directory, this is the current status and this post replaces my two previous posts on the subject:

  • the Raspberry Pi operates locally: everything is in its /opt/FOL directory, which is a mirror of /opt/rtcds/caltech/c1/scripts/FOL/ ; some backup/sync scripts should be set up, tell me what kind (sync direction, place to call the script from, etc..) is recommended and I'll set it up;

 

  • the /opt/FOL directory contains:
    • ADC_interface                 : Akhil's ADC interface software and dependencies;
    • akhilTestCodes                : Akhil's work directory with his programs and data;
    • backup                             : two zip files with a full backup of the FOL stuff for both chiara and domenica at 2014/12/08, before my work on the directory;
    • fcreadoutApp                   : the EPICS app compiled on domenica. I didn't modify anything in particular here, as I don't know much about EPICS Apps; I'm not even sure if it is used by now, as I launch EPICS manually by just giving him a .db file (see below).
    • armFC*                        : it is the single program that constantly fetches data for the channels: it takes as arguments the RPi device (/dev/hidraw0 for the X arm, and /dev/hidraw1 for the Y arm) and the value to write into the frequency counter (0x3 for initialization and 0x2 for actual use); hence, there is no more need for recompilation!
    • epics_channels.py :  this is the new version of the old codetorun.py script; it handles the initialization and the availability of the two beatnote channels;
    • fcreadout / freqCountIOC : these are the binaries of the EPICS apps that I found on chiara/domenica; they are not used as of now, but could be useful;
    • fcreadout.db           : it is the database file that is loaded by EPICS to handle the channels;
    • FOLPID.pl              : the Perl PID controller; it is still the old version, we will work on this one later on (see Manasa's schedule at elog 10760 for info)

 

  • Domenica's environment:
    • as I said, everything runs locally from /opt/FOL;
    • in particular, I added in /etc/inittab two lines that launch EPICS and the python script for the channels; respawn is supported so these processes should always be available. For this to happen, DO NOT MOVE armFC, epics_channels.py and fcreadout.db from the /opt/FOL directory on domenica!
    • I added a udev rule in /etc/udev/rules.d/98-hidraw-permissions.rules to let the controls user access the /dev/hidraw* devices without having to sudo all the time;
    • I updated the ~/.bashrc and /opt/epics/epics-user-env.sh files to fix syntax errors and add some aliases we usually use.
  1744   Tue Jul 14 16:31:46 2009 ClaraUpdatePEMFrequency Response of Microphone (Bonnie)

So, I actually took these measurements last week, but I didn't get around to making nice plots and things until now. I figured the time while I wait for the spectrum analyzer to do its thing was a good time.

Having been unable to locate the SR785 and also unsure how to connect it to a computer speaker (and also unable to find a free one), I downloaded a demo of a function generator onto my computer and just used that. (Same thing I used to do the swept sine that created the frequency power response plots I posted last week.) I set the program to a number of different frequencies and had the other end of the cable hooked into the oscilloscope to see a) if I could pick out the frequency and b) see how the magnitude of the microphone output varied with the frequency.

The first set of measurements I took, I didn't realize that I could increase the output power of the function generator. Because the generated sound at the default setting was relatively quiet, the oscilloscope traces were pretty chaotic, so I usually froze the trace so that I could look at it better. I ended up with a lot of weird jumps in the magnitude, but I later realized that there was a lot of beating going on at some frequencies, and the amplitude changes were probably much more drastic for the -20 dB sounds than the 6 dB sounds, since it was closer in amplitude to the surrounding noises. So, I've included that data set in my plots for the sake of completeness, but I'm pretty sure that it is useless.

Once I realized I could increase the power output for the signal generator, I took a set of data with and without the voltage divider at 6 dB. There was a cluster of frequencies that showed significant beating around 1700-3000 Hz in the data WITH the voltage divider, but I did not see any clear beating in the data WITHOUT. In the plots, I simply plotted up the highest and lowest amplitudes I measured for the frequencies with significant beating, since it was obviously hard to tell what the amplitude would have been without any background noise. In the w/o volt. div. set, although I didn't see any obvious beat patterns, the measured amplitudes did jump slightly at the frequencies that showed beats with the voltage divider. So, perhaps I was just not seeing them, but they influenced my amplitude measurements? I'm not sure if it would be possible for the voltage divider itself to cause beat frequencies.

 (Note: the amplitudes measured were from zero to peak, as the oscilloscope I was using wouldn't show a big enough vertical range to easily measure the peak-to-peak voltage difference.)

I've attached two plots of my measurements. One has a regular x-scale and includes all the measurements. The second has a logarithmic x-scale and omits the 20 Hz points. I had some troubles being able to pick out the 20 Hz signal on the oscilloscope... I don't know if my computer speakers just don't work well at that frequency or what, but either way, those points seemed highly suspect, and omitting them from the log plot allowed me to spread things out more.

One thing I'm not sure about is the 3000 Hz point. It was one of the ones with a beat frequency (~130 Hz), and the amplitudes were pretty low. The corresponding point from the non-voltage-divider data set is also low. So, I'm not sure what's happening there.

The one thing that I do think is quite clear is that the 1000 Hz drop-off in power when the microphone is connected to the ADC has nothing to do with the voltage divider. Beat issues aside, the shapes are very similar (pay no attention to the absolute scale... obviously, the voltage responses with and without the voltage divider were very different, and I just scaled them to fit in the same plot).

Update: Jenne pointed out that I was not absolutely clear about the voltage scale in my plots. The GREEN and BLUE points are on a mV scale, and the RED points are on a 10mV scale. I should probably redo the plots in Matlab in eventuality, since Excel is hard to use if you want to do anything that is not extremely basic with your plots, but this was my solution for the time being. So, the fact that the RED points, which are the data taken WITHOUT the voltage divider, are lower than the GREEN ones does not in any way indicate that I measured lower voltages when the voltage divider was not used.

Also, a to do list:

- Many of the beat frequencies I picked out were veeeeery slow, indicating that something is going at a frequency that is very close to the arbitrary frequencies I chose to sample, which is a little strange. That, combined with the fact that I saw clear beats with the voltage divider but not without leads me to believe that it may be worth investigating the frequency response of the voltage divider itself.

- Redo the measurements near the anomalous 3000 Hz point with a higher density of sampled frequencies to try to see what the heck is going on there.

Attachment 1: Bonnie_fres_regplot.pdf
Bonnie_fres_regplot.pdf
Attachment 2: Bonnie_fres_logplot.pdf
Bonnie_fres_logplot.pdf
ELOG V3.1.3-