40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 337 of 341  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Type Category Subjectdown
  9073   Tue Aug 27 18:58:52 2013 KojiConfigurationElectronics110 MHz LO options

- Do we have an appropriate amplifier?

- True challenge could be to find a feedthrough for the new port. (or to find a space for the amplifier in the box)

- PDXXX channels is on the DC whitening filter module. There could be some modification on this module (like diabling the whitening gain selector).

- We don't have AS11 and AS165, and so far it is unlikely to use AS11. i.e. The feedthrough, the slot on the crate, the whitening, and the channels can be trasnsition from 11 to 110.

Quote:

I want to amplify that by ~10 dB, to give 9 dBm.  Attenuate by 5 dB to get to 4 dBm, then split into 2, giving me 2 110 MHz spigots, each of ~1 dBm. 

Thoughts, before I start scrounging parts, and pulling the RF distribution box?

 

  7360   Fri Sep 7 12:28:09 2012 KojiUpdateLSC11&55MHz modulations turned off

11MHz modulation source was turned off (disabled) at Marconi at 12:00.

  845   Mon Aug 18 09:19:55 2008 steveSummaryVAC11 days at atm
It took 11 days to fix earth quake triggered sus problems of ITMX, SRM and PRM
Only ITMX north and BSC north vac doors were removed.

The PRM sus had to be removed form the vac envelope for "hip replacement"-new wire stand off was
epoxied in place.
Note: the PRM has no guide rod on the other side

ITMX, SRM and BS osems were optimized in place.
No crosscoupling optimization was performed.
Beam block was removed from ITMXC, it was too close to the main beam.

POX pick off mirror and mount will be replaced next vent.

Vac viewports were inspected from the inside.
Attachment 1: ventprm.jpg
ventprm.jpg
  7515   Wed Oct 10 02:15:14 2012 ranaUpdateLSC11 MHz reconnected to EOM

 Absolutely hokey. What are our requirements for this RFPD? What are the power levels and SNR that we want (I seem to remember that its for 22 as well as 110 MHz)? Perhaps we can test an aLIGO one if Rich has one sitting around, or if the aLIGO idea is to use a broadband PD I guess we can just keep using what we have.

  2653   Wed Mar 3 18:32:25 2010 AlbertoUpdate40m Upgrading11 MHz RFPD elctronics
** Please add LISO file w/ component values.
 
I designed the circuit for one of the 11 MHz photodiodes that we're going to install in the 40m Upgrade.

This is a simple representation of the schematic:

          gnd
#          |
#          Cw2
#          |
#          n23
#          |
#          Lw2
#          |
#           n22
#          |
#          Rw2                
#                 |                   |\            
#           n2- - - C2 - n3 -  - -  - |  \          
#            |    |      |   |        |4106>-- n5 - Rs -- no
# iinput    Rd   L1     L2 R24    n6- |  /     |           |
#      nin - |    |      |   |    |   |/       |         Rload    
#           Cd   n7     R22 gnd   |            |           |          
#            |    |      |        | - - - R8 - -          gnd              
#           gnd  R1     gnd      R7 
#                 |               |
#         gnd               gnd
#                 
#
#

I chose the values of the components in a realistic way, that is using part available from Coilcraft or Digikey.

Using LISO I simulated the Tranfer Function and the noise of the circuit.

I'm attaching the results.

I'll post the 55MHz rfpd later.

Attachment 1: rfpd11_v2_TF.pdf
rfpd11_v2_TF.pdf
Attachment 2: rfpd11_v2_Noise.pdf
rfpd11_v2_Noise.pdf
  2655   Thu Mar 4 08:43:35 2010 AlbertoUpdate40m Upgrading11 MHz RFPD elctronics

Quote:
** Please add LISO file w/ component values.

oops, forgotten the third attachment...

here it is

Attachment 1: rfpd11_v2.fil
# Resonant RF diode front end
#
#		  gnd
#		  |
#		  Cw2
#		  |
#		  n23
#		  |
#		  Lw2
#		  |
... 60 more lines ...
  12949   Fri Apr 21 13:59:47 2017 Eric GustafsonSummary 1064 nm Semiconductor Laser Fiber Distribution System and Mirror Tomography

1064 nm Semiconductor Laser Fiber Distribution System and Mirror Tomography

Below threshold these Semiconductor Fabry-Perot lasers have an axial mode structure with a spacing of about a THz. As you turn up the current to above threshold the first mode to oscillate saturates the gain down on all the modes and only it oscillates.  The laser I have here in my office (a backup for the one you have at the 40 meter) has a wavelength of 1064.9 nm at 70 Degrees C.  We should be able to temperature tune it down to 1064.3 nm although this could be a bit tedious the first time we do it. The specifications claim a "spectrum width" of 1.097 nm which I believe is the temperature tuning range.  I don’t know what the line width is but it will be single frequency and we shouldn’t have mode hoping problems.  So we should be able to use it in the “Mirror Tomography” experiment.  You might want to use some sort of polarization diversity to avoid the problems of fiber polarization drift.

There have been 2 student projects on using the fiber distributed PD frequency response at1064 nm laser.

“Automated Photodiode Frequency Response Measurement System,” Alexander Cole - T1300618

“Final Report: Automated Photodiode Frequency Response Measurement System for Caltech 40m lab,” Nichin Sreekantaswamy - P140021

I’ll look up a few more references and add include them in the next elog.

Eric

 

  9253   Fri Oct 18 08:12:08 2013 SteveUpdatePEM1000 days trends
Attachment 1: trend1000days.png
trend1000days.png
  1640   Mon Jun 1 19:19:26 2009 ranaUpdatePSL1000 days of hour-trend
Attachment 1: u.png
u.png
  9482   Tue Dec 17 20:59:23 2013 JenneUpdateLSC1/sqrt(TR) signals added to frames

I noticed that we have not been saving the 1/sqrt(TRX) and 1/sqrt(TRY) data, so I modified the c1lsc model and added them to the DAQ channels block.  I restarted the c1lsc model, and the _DQ channels are now archived.

  3171   Wed Jul 7 19:41:27 2010 JenneUpdateSUS1.5 more ECD sets suspended for tip tilts

[Jenne, Kyung Ha]

We made some good progress on suspending the Tip Tilt ECDs today.  We finished one whole set, plus another half.  The half is because one of the screw holes on the lower right ECD somehow got cross threaded.  The ECD and screws in question were separately wrapped in foil to mark them as iffy.  We'll redo that second half tomorrow.  This makes a total of 2.5 (including yesterday's work) ECD backplanes suspended.  The only thing left for these ones is to trim up the excess wire.

We also (with Koji) took a look at the jig used for suspending the mirror holder.  It looks like it was designed for so many Tip Tilt generations ago as to be basically useless for the 40m TTs.  The only really useful thing we'll get out of it is the distance between the suspension block and the mirror holder clamps.  Other than that we'll have to make do by holding the mirror and block at the correct distance apart, utilizing a ruler, calipers, or similar.  Rana pointed out that we should slightly bend the blade springs up a bit, so that when they are holding the load of the mirror holder, they sit flat. 

Attached below are 2 different pictures of one of the ECD backplane sets that has been suspended.  One with black background to illustrate the general structure, and one with foil background to emphasize the wires.

Attachment 1: ECDbackplane_blackdump_small.jpg
ECDbackplane_blackdump_small.jpg
Attachment 2: ECDbackplane_foil_small.jpg
ECDbackplane_foil_small.jpg
  8008   Wed Feb 6 14:51:25 2013 JenneUpdateElectronics1 power supply replaced!

Quote:

Currently, DC power for amplifiers ZHL-1000LN+ is supplied by Aligent E3620A.
I tried to use power supply from the side of 1X1 rack, but fuse plug(Phoenix Contact ST-SI-UK-4) showed red LED, so I couldn't use it.

 Yuta, Jenne

We fixed things so that we are now using regular fused rack power for these amplifiers.  The fuse no longer had a red LED, but it measured open when we checked the resistance.  Although, somehow (magic?) 13.73V were getting to the other side of the fuse. 

Anyhow, replacing the fuse with a new one fixed the problem right up.

  6496   Fri Apr 6 15:06:05 2012 DenUpdateIOO1 Hz resonance

I think we can try to damp 1 Hz resonance more. In September it was not seen because of the digital noise. After we've figured it out, 1 Hz resonance began to be more clear (blue line).

psd_mcl.jpg

Now applying oaf we reduce the effect of the stack and the 1 Hz resonance is even more clear:

mcl.jpg

 

  7234   Mon Aug 20 13:02:57 2012 DenUpdateAdaptive Filtering1 Hz resonance

Static filter was adjusted to filter 1 Hz resonance in MCL and it could do it. Stack is not great in this experiment due to the phase mismatch. I'll fix it.

1hz.png

  11986   Thu Feb 11 14:28:50 2016 SteveUpdateTreasure091415 declared

   Beautifully Done

   Chirp

  what is next?

Atm 3, Ron Drever could not celebrate with us because of health issues.

 

Attachment 1: 091415declared.jpg
091415declared.jpg
Attachment 2: You_were_right!.jpg
You_were_right!.jpg
Attachment 3: P1080312.JPG
P1080312.JPG
  9042   Tue Aug 20 16:23:41 2013 ranaSummaryGeneral/home/cds nearly full

/home/cds is >98% full - below are some of the usage numbers:

controls@rosalba:/users/OLD 0$ du -h --max-depth=1
42M    ./katrin
1.5M    ./ben
2.4M    ./sanjit
569M    ./waldman
328M    ./sonia
3.6G    ./lsinger
44M    ./dbusby
105M    ./dbarron
21M    ./manuel
709M    ./yaakov
46M    ./rodionov
240M    ./ishwita
2.7G    ./clara
56M    ./gopal
290M    ./mashaB
87M    ./varvella
5.6M    ./Sascha
2.9G    ./ryan
190M    ./nancy
3.5G    ./john
269M    ./elizabeth.davison
165M    ./jweiner
460K    ./mjones
49M    ./stephanie
52M    ./mohana
56M    ./noriyasu
38M    ./mjenson
76M    ./sballmer
224M    ./kirk
812K    ./bonnie
33M    ./janosch
16M    ./kevin
122M    ./dblair
2.6G    ./mirko
389M    ./keenan
195M    ./tf
150M    ./littlezach
193M    ./jmiller
1.8G    ./ting
131M    ./dmalling
842M    ./sharmila
1.4G    ./caryn
12G    ./rward
4.1M    ./jay
443M    ./emintun
184M    ./katharine
76K    ./nick
804K    ./nicole.ing
14M    ./jenny
542M    ./vsanni
45M    ./peter
7.8G    ./miyakawa
4.8M    ./channa
4.0K    ./frank
9.9G    ./razib
35M    ./amin
361M    ./sharon
62M    ./bram
3.9M    ./volodya
7.9M    ./larisa
301M    ./sasha
33M    ./eric.hendries
18M    ./vuk
101M    ./huan
1.8M    ./sonali
453M    ./megan
43M    ./Royal
5.4G    ./ayaka
19M    ./mott
518M    ./justing
501M    ./avi
173M    ./kakeru
3.9G    ./alberto
41M    ./paul.fulda
59M    ./elena
67G    .

controls@rosalba:/opt/rtcds/userapps 0$ du -h --max-depth=1
1.4G    ./tags
13M    ./trunk.bak
40K    ./.svn
3.0G    ./trunk
174M    ./trunk.bak2
4.2G    ./branches
8.7G    .

linux1:cds>nice du -h --max-depth=1
du: `./llo/chans/daq/archive': Permission denied
du: `./llo/chans/daq/old': Permission denied
707M    ./llo
9.7M    ./mit~
752K    ./raidwebFirmware
462M    ./epics
2.1G    ./tmp
1.5G    ./gds
76M    ./project
9.1G    ./ligo
449G    ./rtcds
3.3G    ./apps
20K    ./.kde
512K    ./cdscfg
1.4M    ./.Trash-controls
5.8M    ./scripts
20K    ./.TemporaryItems
964G    ./caltech
71M    ./bin
16K    ./.Trash-1001
4.5G    ./rtapps
564M    ./src
11M    ./vw
3.8M    ./dvSave
460M    ./lho
1.2G    ./data
1.5T    .

  9045   Wed Aug 21 17:42:03 2013 ranaSummaryGeneral/home/cds nearly full

One of the reasons that our disk is getting full is due to the scripts_archive directory. A backup script runs on op340m and makes a tar.bz2 file of the scripts directory and puts it in scripts_archive every morning at 6 AM.

On Oct 7, 2011, Koji fixed this script to point at our new scripts directory instead of the old /cvs/cds/caltech/scripts directory. Since then, however, no one has fixed the exclude file to NOT back up the junk that's in that directory. Its a 1.6 GB directory so its full of it.

I've deleted a bunch of junk from the scripts directory: this directory is for scripts, not for your personal home movies or junk data files. Put those in your USER directory. Put temporary data files in /tmp/. I've also added a few more patterns to the exclude file so that less .mpg, .png, .pdf, .dat, etc get stored every day. The new daily .tar.bz2 file wil be ~25 MB instead of 770 MB.

(also fixed the backup script to use 'env' to setup the perl environment and removed the hard-coded path to tar)

  9147   Fri Sep 20 20:14:52 2013 ranaSummaryGeneral/home/cds nearly full

Quote:

One of the reasons that our disk is getting full is due to the scripts_archive directory. A backup script runs on op340m and makes a tar.bz2 file of the scripts directory and puts it in scripts_archive every morning at 6 AM.

On Oct 7, 2011, Koji fixed this script to point at our new scripts directory instead of the old /cvs/cds/caltech/scripts directory. Since then, however, no one has fixed the exclude file to NOT back up the junk that's in that directory. Its a 1.6 GB directory so its full of it.

I've deleted a bunch of junk from the scripts directory: this directory is for scripts, not for your personal home movies or junk data files. Put those in your USER directory. Put temporary data files in /tmp/. I've also added a few more patterns to the exclude file so that less .mpg, .png, .pdf, .dat, etc get stored every day. The new daily .tar.bz2 file wil be ~25 MB instead of 770 MB.

(also fixed the backup script to use 'env' to setup the perl environment and removed the hard-coded path to tar)

 OUr disk was getting full again. Turned out my "fix" to 25 MB was only a fix to 250 MB. Since we were getting disk full warnings on our Ubuntu workstations, I deleted some COMSOL.dmg files from users/zach/ and then started deleting every other tarball from the scripts_archive directory. ~221 GB are now free. Still need to fix the exclude file for scripts better.

  9535   Tue Jan 7 23:50:27 2014 jamieUpdateCDS/frames space cleared up, daqd stabilized

The wiper script is done and deleted a whole bunch of stuff to clean up some space:

controls@fb ~ 0$ /opt/rtcds/caltech/c1/target/fb/wiper.pl --delete

Tue Jan  7 23:09:21 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385927520k
/frames/trend/second 125729084k
/frames/full 12552144324k
/frames/trend/minute 2311404k
Combined 13066112332k or 12759875m or 12460Gb

/frames size 13460088620k at 97.07%
/frames above keep value of 95.00%
Frame area size is 12401156668k
/frames/full size 12552144324k keep 11781098835k
/frames/trend/second size 125729084k keep 24802313k
/frames/trend/minute size 2311404k keep 620057k
Deleting some full frames to free 771045488k
- /frames/full/10685/C-R-1068567600-16.gwf
- /frames/full/10685/C-R-1068567616-16.gwf
...
controls@fb ~ 0$ df -h /frames
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   12T  826G  94% /frames
controls@fb ~ 0$
So it cleaned up 826G of space.  It looks like the fb is stabilized for the moment.  On site folks should confirm...

 

asdfasdfsadf sadf asdf

  9949   Tue May 13 17:45:21 2014 ranaUpdateCDS/frames space cleared up, daqd stabilized

 

 Late last night we were getting some problems with DAQD again. Turned out to be /frames getting full again.

I deleted a bunch of old frame files by hand around 3AM to be able to keep locking quickly and then also ran the wiper script (target/fb/wiper.pl).

controls@pianosa|fb> df -h; date

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda1             440G  9.7G  408G   3% /

none                  7.9G  288K  7.9G   1% /dev

none                  7.9G  464K  7.9G   1% /dev/shm

none                  7.9G  144K  7.9G   1% /var/run

none                  7.9G     0  7.9G   0% /var/lock

none                  7.9G     0  7.9G   0% /lib/init/rw

none                  440G  9.7G  408G   3% /var/lib/ureadahead/debugfs

linux1:/home/cds      1.8T  1.4T  325G  82% /cvs/cds

linux1:/ligo           71G   18G   50G  27% /ligo

linux1:/home/cds/rtcds

                      1.8T  1.4T  325G  82% /opt/rtcds

fb:/frames        13T   12T  559G  96% /frames

linux1:/home/cds/caltech/users

                      1.8T  1.4T  325G  82% /users

Tue May 13 17:35:00 PDT 2014

Looking through the directories by hand it seems that the issue may be due to our FB MXstream instabilities. The wiper looks at the disk usage and tries to delete just enough files to keep us below 95% full for the next 24 hours. If, however, some of the channels are not being written because some front ends are not writing their DAQ channels to frames, then it will misestimate the disk size. In particular, if its currently writing small frames and then we restart the mxstream and the per frame file size goes back up to 80 MB, it can make the disk full.

For now, I have modified the wiper.pl script to try to stay below 93%. As you can see by the above output of 'df', it is already above 96% and it still has files to write until the next run of wiper.pl 7 hours from now at. at 6 AM.

IF we assume that its writing a 75MB file every 16 seconds, then it would write 405 GB of frames every day. There is 559 GB free right now so we are OK for now. With 405 GB of usage per day, we have a lookback of ~12TB/405GB ~ 29 days (ignoring the trend files).

  9955   Thu May 15 01:42:07 2014 ranaUpdateCDS/frames space cleared up, daqd stabilized

 Script seems to be working now:

nodus:~>df -h | grep frames

fb:/frames              13T    12T   931G    93%    /frames

  9531   Tue Jan 7 23:08:01 2014 jamieUpdateCDS/frames is full, causing daqd to die

Quote:

The daqd process is segfaulting and restarting itself every 30 seconds or so.  It's pretty frustrating. 

Just for kicks, I tried an mxstream restart, clearing the testpoints, and restarting the daqd process, but none of things changed anything.  

Manasa found an elog from a year ago (elog 7105 and preceding), but I'm not sure that it's a similar / related problem.  Jamie, please help us

The problem is not exactly the same as what's described in 7105, but the symptoms are so similar I assumed they must have a similar source.

And sure enough, /frames is completely full:

controls@fb /opt/rtcds/caltech/c1/target/fb 0$ df -h /frames/
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   13T     0 100% /frames
controls@fb /opt/rtcds/caltech/c1/target/fb 0$

So the problem in both cases was that it couldn't write out the frames.  Unfortunately daqd is apparently too stupid to give us a reasonable error message about what's going on.

So why is /frames full?  Apparently the wiper script is either not running, or is failing to do it's job.  My guess is that this is a side effect of the linux1 raid failure we had over xmas.

  9533   Tue Jan 7 23:13:47 2014 jamieUpdateCDS/frames is full, causing daqd to die

Quote:

So why is /frames full?  Apparently the wiper script is either not running, or is failing to do it's job.  My guess is that this is a side effect of the linux1 raid failure we had over xmas.

It actually looks like the wiper script has been running fine.  There is a log from Tuesday morning:

controls@fb ~ 0$ cat /opt/rtcds/caltech/c1/target/fb/wiper.log

Tue Jan  7 06:00:02 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385289132k
/frames/trend/second 100891124k
/frames/full 12269554048k
/frames/trend/minute 1906772k
Combined 12757641076k or 12458633m or 12166Gb

/frames size 13460088620k at 94.78%
/frames is below keep value of 95.00%
Will not delete any files
df reported usage 97.72%
controls@fb ~ 0$

So now I'm wondering if something else has been filling up the frames today.  Has anything changed today that might cause more data than usual to be written to frames?

I'm manually running the wiper script now to clear up some /frames.  Hopefully that will solve the problem temporarily.

  12796   Fri Feb 3 11:40:34 2017 ericqSummaryCDS/cvs/cds/caltech/chans back on svn1.6

I was able to bring back svn 1.6 formatting to /cvs/cds/caltech/chans by doing the following on nodus:

cd /cvs/cds/caltech
mkdir newchans
cd newchans
svn co https://nodus.ligo.caltech.edu:30889/svn/trunk/chans ./
rm -rf ../chans/.svn
mv ./.svn ../chans/

Note that I used the http address for the repository. The svn repository doesn't live at file:///cvs/cds/caltech/svn anymore; all of our checkouts (e.g. in the scripts directory) use http to get the one true repo location, regardless of where it lives on nodus' filesystem. (I suppose we could also use https://nodus.martian:30889/svn to stick to the local network, but I don't think we're that limited by the caltech network speed)

Presumably, at some point we will want to introduce a newer operating system into the 40m, as ubuntu 12.04 hits end-of-life in April 2017. Ubuntu 16.04 includes svn 1.8, so we'll also hit this issue if we choose that OS. 


Aside from the svn issues, this directory (/cvs/cds/caltech/chans) only contains pre-2010 channels. Filters and DAQ ini files currently live in /opt/rtcds/caltech/c1/chans, which is not under version control. It's also not clear to me why summary page configurations should be kept in this /cvs/cds place.

  12797   Sat Feb 4 12:00:59 2017 ranaSummaryCDS/cvs/cds/caltech/chans back on svn1.6

True - its an issue. Koji and I are updating zita into Ubuntu16 LTS. If it looks like its OK with various tools we'll swap over the others into it. Until then I figure we're best off turning allegra back into Ubuntu12 to avoid a repeat of this kind of conflict. Once the workstations in the LLO control room are running smoothly on a new OS for a year, we can transfer into that. I don't think any of us wants to be the CDS beta tester for DV or DTT.

  12798   Sat Feb 4 12:20:39 2017 jamieSummaryCDS/cvs/cds/caltech/chans back on svn1.6
Quote:

True - its an issue. Koji and I are updating zita into Ubuntu16 LTS. If it looks like its OK with various tools we'll swap over the others into it. Until then I figure we're best off turning allegra back into Ubuntu12 to avoid a repeat of this kind of conflict. Once the workstations in the LLO control room are running smoothly on a new OS for a year, we can transfer into that. I don't think any of us wants to be the CDS beta tester for DV or DTT.

Just to be clear, since there seems to be some confusion, the SVN issue has nothing to do with Debian vs. Ubuntu.  SVN made non-backwards compatible changes to their working copy data format that breaks newer checkouts with older clients.  You will run into the exact same problem with newer Ubuntu versions.

I recommend the 40m start moving towards the reference operating systems (Debian 8 or SL7) as that's where CDS is moving.  By moving to newer Ubuntu versions you're moving away from CDS support, not towards it.

  12799   Sat Feb 4 12:29:20 2017 jamieSummaryCDS/cvs/cds/caltech/chans back on svn1.6

No, not confused on that point. We just will not be testing OS versions at the 40m or running multiple OS's on our workstations. As I've said before, we will only move to so-called 'reference' systems once they've been in use for a long time.

Quote:
Quote:

True - its an issue. Koji and I are updating zita into Ubuntu16 LTS. If it looks like its OK with various tools we'll swap over the others into it. Until then I figure we're best off turning allegra back into Ubuntu12 to avoid a repeat of this kind of conflict. Once the workstations in the LLO control room are running smoothly on a new OS for a year, we can transfer into that. I don't think any of us wants to be the CDS beta tester for DV or DTT.

Just to be clear, since there seems to be some confusion, the SVN issue has nothing to do with Debian vs. Ubuntu.  SVN made non-backwards compatible changes to their working copy data format that breaks newer checkouts with older clients.  You will run into the exact same problem with newer Ubuntu versions.

I recommend the 40m start moving towards the reference operating systems (Debian 8 or SL7) as that's where CDS is moving.  By moving to newer Ubuntu versions you're moving away from CDS support, not towards it.

 

  12800   Sat Feb 4 12:50:01 2017 jamieSummaryCDS/cvs/cds/caltech/chans back on svn1.6
Quote:

No, not confused on that point. We just will not be testing OS versions at the 40m or running multiple OS's on our workstations. As I've said before, we will only move to so-called 'reference' systems once they've been in use for a long time.

Ubuntu16 is not to my knowledge used for any CDS system anywhere.  I'm not sure how you expect to have better support for that.  There are no pre-compiled packages of any kind available for Ubuntu16.  Good luck, you big smelly doofuses. Nyah, nyah, nyah.

  12914   Tue Mar 28 21:06:53 2017 ranaSummaryCDS/cvs/cds/caltech/chans back on svn1.6

Debian doesn't like EPICS. Or our XY plots of beam spots...Sad!

Quote:
Quote:

No, not confused on that point. We just will not be testing OS versions at the 40m or running multiple OS's on our workstations. As I've said before, we will only move to so-called 'reference' systems once they've been in use for a long time.

Ubuntu16 is not to my knowledge used for any CDS system anywhere.  I'm not sure how you expect to have better support for that.  There are no pre-compiled packages of any kind available for Ubuntu16.  Good luck, you big smelly doofuses. Nyah, nyah, nyah.

  1059   Mon Oct 20 15:02:00 2008 YoichiConfigurationComputers/cvs/cds restored
I moved missing files in /cvs/cds restored by Alan and Stuart to the original locations.
I confirmed autoburt runs, and dtt, which had also been having trouble running, runs ok now.

I found an interesting piece of evidence on allegra, our new 64bit linux machine.
In the Trash of controls Desktop on that machine, there is /cvs/cds/vw/ directory.
I remember that when I last time emptied the trash bin on the machine (yesterday), it took somewhat long time.
Too bad that I did not pay attention to what was actually in the Trash, but now I have a feeling that in the Trash were
missing /cvs/cds/* directories.
While emptying the Trash, I encountered several errors saying permission denied or something like that, and skipped those files.
Sometimes, when you move something from NFS mounted directories to the Trash, you get this kind of errors.
So my guess is that someone accidentally (or intentionally) moved /cvs/cds/* except for "caltech" to the Trash of allegra.
And I completely removed them carelessly.
  1060   Mon Oct 20 16:18:00 2008 AlanConfigurationComputers/cvs/cds restored

Quote:
I moved missing files in /cvs/cds restored by Alan and Stuart to the original locations.
I confirmed autoburt runs, and dtt, which had also been having trouble running, runs ok now.

I found an interesting piece of evidence on allegra, our new 64bit linux machine.
In the Trash of controls Desktop on that machine, there is /cvs/cds/vw/ directory.
I remember that when I last time emptied the trash bin on the machine (yesterday), it took somewhat long time.
Too bad that I did not pay attention to what was actually in the Trash, but now I have a feeling that in the Trash were
missing /cvs/cds/* directories.
While emptying the Trash, I encountered several errors saying permission denied or something like that, and skipped those files.
Sometimes, when you move something from NFS mounted directories to the Trash, you get this kind of errors.
So my guess is that someone accidentally (or intentionally) moved /cvs/cds/* except for "caltech" to the Trash of allegra.
And I completely removed them carelessly.


In the meantime, I have re-started the nightly backup for /frames/minute-trends
but NOT YET for /cvs/cds ,
since I fear that we'll find another problem and will need to go back to the June 27 backup.
Let's wait a few days for the dust to settle,
and if everyone feels confident that /cvs/cds is ok,
I'll restart the backup of that.

How I restored the files, for the record:

Stuart mounted /archive/backup onto an accessible computer (garrak.ligo.caltech.edu ) and I logged on to controls@nodus and ran this command:

/cvs/cds/caltech/scripts/backup/rsync --rsync-path=/usr/bin/rsync --rsh=/usr/bin/ssh --compress --verbose --archive --hard-links --exclude=caltech/ ajw@garrak.ligo.caltech.edu:/backup/40m/cvs /cvs/cds/recover_20081020

I had to type in my GC password, and it ran for ~20 minutes (would have been much longer had I asked for /cvs/cds/caltech as well!).

you can view the backups by logging on to garrak.ligo.caltech.edu with your GC account:
/backup/40m/cvs/cds/
/archive/frames/trend/minute-trend/40m
  13929   Thu Jun 7 20:21:15 2018 KojiUpdateComputer Scripts / Programs/cvs/cds Backup in danger

Local backup on chiara seems not working since Nov 19, 2017.
/opt/rtcds/caltech/c1/scripts/backup/localbackup.log

2017-11-18 07:00:01,504 INFO       Updating backup image of /cvs/cds
2017-11-18 07:03:00,113 INFO       Backup rsync job ran successfully, transferred 1954 files.
2017-11-19 07:00:02,564 INFO       Updating backup image of /cvs/cds
2017-11-19 07:00:02,592 ERROR      External drive not mounted!!!

  13963   Thu Jun 14 15:21:58 2018 gautamUpdateComputer Scripts / Programs/cvs/cds Backup in danger

I think this is because /cvs/cds is getting too big. lsblk reveals:

controls@chiara|~> lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk 
├─sda1   8:1    0 446.9G  0 part /
├─sda2   8:2    0     1K  0 part 
└─sda5   8:5    0  18.9G  0 part [SWAP]
sdb      8:16   0   2.7T  0 disk 
└─sdb1   8:17   0     2T  0 part /home/cds
sr0     11:0    1  1024M  0 rom  
sdc      8:32   0   1.8T  0 disk 
└─sdc1   8:33   0   1.8T  0 part /media/40mBackup
sdd      8:48   0   1.8T  0 disk 
└─sdd1   8:49   0   1.8T  0 part 

I believe one of sdc or sdd is connected via SATA while the other is an external USB drive. Maybe we have to get bigger backup disks, but this may be a huge pain to setup as it will involve taking chiara down. Actually, now that I check the backup log, seems like backup is executing successfully - not sure if this is due to my unelogged mounting of sdc (using sudo mount /dev/sdc1 /media/40mBackup) last week, or if this is some LDAS backup. But in any case, seems undesirable that sdb1 is larger than sdc1 or sdd1.

2018-06-06 07:00:01,086 INFO       Updating backup image of /cvs/cds
2018-06-06 07:00:01,086 ERROR      External drive not mounted!!!
2018-06-07 07:00:01,147 INFO       Updating backup image of /cvs/cds
2018-06-07 07:00:01,147 ERROR      External drive not mounted!!!
2018-06-08 07:00:01,244 INFO       Updating backup image of /cvs/cds
2018-06-08 08:23:32,939 INFO       Backup rsync job ran successfully, transferred 316870 files.
2018-06-09 07:00:01,465 INFO       Updating backup image of /cvs/cds
2018-06-09 07:12:11,865 INFO       Backup rsync job ran successfully, transferred 1926 files.
2018-06-10 07:00:01,842 INFO       Updating backup image of /cvs/cds
2018-06-10 07:12:28,931 INFO       Backup rsync job ran successfully, transferred 1656 files.
2018-06-11 07:00:01,294 INFO       Updating backup image of /cvs/cds
2018-06-11 07:06:14,748 INFO       Backup rsync job ran successfully, transferred 1664 files.
2018-06-12 07:00:02,081 INFO       Updating backup image of /cvs/cds
2018-06-12 07:07:36,775 INFO       Backup rsync job ran successfully, transferred 1870 files.
2018-06-13 07:00:02,194 INFO       Updating backup image of /cvs/cds
2018-06-13 07:08:37,356 INFO       Backup rsync job ran successfully, transferred 1818 files.
2018-06-14 07:00:01,753 INFO       Updating backup image of /cvs/cds
2018-06-14 07:01:43,270 INFO       Backup rsync job ran successfully, transferred 1744 files.
Quote:

Local backup on chiara seems not working since Nov 19, 2017.
/opt/rtcds/caltech/c1/scripts/backup/localbackup.log

2017-11-18 07:00:01,504 INFO       Updating backup image of /cvs/cds
2017-11-18 07:03:00,113 INFO       Backup rsync job ran successfully, transferred 1954 files.
2017-11-19 07:00:02,564 INFO       Updating backup image of /cvs/cds
2017-11-19 07:00:02,592 ERROR      External drive not mounted!!!

 

  1683   Wed Jun 17 01:09:47 2009 robUpdateComputers/cvs/cds 91% full

In /cvs/cds/caltech

 


1.6M    2008-8-15.pdf
2.9M    40mUpgradeOpticalLayoutPlan01.pdf
2.4M    alh
19M     apache
18G     apps
11M     archive
4.0K    authorized_keys2
8.0K    backup.notes
8.0K    backup.notes~
1.9G    build
62G     burt
47M     cds
13M     cds40m
37M     chans
70G     conlog
52K     crontab
12K     cshrc.40m
12K     cshrc.40m~
36M     diag
1.4G    dmt
8.2M    framecpp-0.2.0
1.7M    free_080730.pdf
57M     gds
9.8G    home
60K     hooks
8.0K    hosts.40m
4.0K    id_rsa
10M     iscmodeling
110M    ldg-4.7
648M    libs
4.0K    log2.txt
224K    logs
0       log.txt
238M    medm
344M    NB
148M    NB_080304
211M    NB_080307
401M    NB40
1.2G    noisebudget.071109
837M    noisebudget.bak.20060623
3.5M    oldtarget
123M    root
5.7M    savesets
208K    schematics
655M    scripts
13G     scripts_archive
1.1M    state
3.7G    svn
4.0K    svn-commit.tmp
7.3G    target
295M    target_archive
6.7M    test
72K     test.png
4.0K    tmp
8.0K    typescript
35G     users
205M    wind

  583   Fri Jun 27 15:20:52 2008 robDAQLSC.ini file change

I removed C1:LSC-XARM_CTRL from the frames and added C1:LSC-CARM_ERR
  6683   Fri May 25 16:58:54 2012 JamieConfigurationComputers.bashrc for workstations

I have setup a shared .bashrc for all the workstations that is symlinked to the normal location on all machines:

controls@rossa:~ 0$ ls -al /home/controls/.bashrc 
lrwxrwxrwx 1 controls controls 23 2012-05-25 15:37 /home/controls/.bashrc -> /users/controls/.bashrc
controls@rossa:~ 0$ 

This should help simplify maintenance considerably.  Editing that file on one machine will edit it for all.  Just edit this one file!  Don't try to get fancy and add extra files!

I also added a bunch of aliases that had previously been missing.  This should help with some of the problems that people had been having.

NOTE: PLEASE DO NOT CHANGE THE DEFAULT SHELL!  We are using bash, because that's what the sites are now using and we want to be as compatible as possible.

You can of course still write scripts in csh/tcsh or use tcsh in a shell if you wish.   Just don't change the default shell for the controls user.

  732   Thu Jul 24 03:08:20 2008 robUpdateLocking+f2 DRMI+2ARMS

rob, john, yoichi

Tonight we tried to move the 166MHz (f2) sideband frequency by changing the settings on the Marconi. Reducing the frequency by 4kHz reduced the amplitude of the 166MHz sidebands, but we were still able to lock the DRMI with the +-f2 sidebands by electronically compensating for the gain decrease, and also to lock the DRMI+2ARMs while resonating the -f2 sideband. No luck with the +f2.

Then we larkily tried increasing the frequency by 4kHz, which ~doubled the f2 sideband transmission through the MC. This means our frequencies/MC length have been mismatched for months. Apparently I explained the level of the f2 sidebands by just imagining that I'd (or someone) had set the modulation depth at that level some time in the past.

It's a miracle any locking worked at all in this state. Once this was done and we worked out a few kinks in the script, adjusting some gains to compensate, we managed to get the DRMI+2ARMS to lock a couple of times while resonating the +f2 sideband. It takes a while, but at least it happens. Tomorrow we'll measure the length of the mode cleaner properly and then try again. No need to vent just yet.
  10472   Mon Sep 8 15:50:47 2014 ericqUpdateComputer Scripts / Programs+15V PSL Sorensen replaced

We replaced the +15V sorensen at 1X1, and brought the power supplies back up symmetrically, and everything seems fine. I noted that a quarter turn counter-clockwise took the current limit down by one amp, so I set the knob to just letting 2.8A (the nominal current), and then added one half turn, shooting for ~4A current limit. 

In doing so, we had to cut power to the c1psl VME box. It didn't come back happily. We had to do the chiara /etc/hosts things, like we did for c1auxexx, to get it back.

  14928   Thu Oct 3 11:01:18 2019 ranaUpdateLSC(PR)FPMI locking

wonder if its possible to do variable finesse locking

Gabriele mentioned that Virgo used arm trans PDH for this, but I guess we could possibly use POX/POY to start and bring in the PRM with 50% MICH trans

  3376   Fri Aug 6 15:50:29 2010 GopalUpdateOptic Stacks(Much Better Looking) Displacement-Displacment Transfer Functions

I reran the FDA in COMSOL on the MC1/MC3 Stack and produced the following Displacement-Displacement Transfer Functions:

X-Translational Drive has a blue background

Y-Translational Drive has a red background

Z-Translational Drive has a green background

Obtaining the Displacement-to-Phase part of the Transfer Function still produces difficulties -- I'm still working on the COMSOL-Matlab interface to perhaps better facilitate this.

RA: I have deleted those plots because they weren't transfer functions. Transfer functions must always be the ratio of something to something. For example: if I had a nickel for every bad plot I see, I would be a millionaire. In that example, the transfer function would have the units of nickels/plots. For the stacks, it should be meters/meter.

 

Attachment 1: MC1_MC3_XTrans.png
MC1_MC3_XTrans.png
Attachment 2: MC1_MC3_YTrans.png
MC1_MC3_YTrans.png
Attachment 3: MC1_MC3_ZTrans.png
MC1_MC3_ZTrans.png
  3380   Fri Aug 6 19:46:59 2010 GopalUpdateOptic Stacks(Much Better Looking) Displacement-Displacment Transfer Functions

Quote:

I reran the FDA in COMSOL on the MC1/MC3 Stack and produced the following Displacement-Displacement Transfer Functions:

X-Translational Drive has a blue background

Y-Translational Drive has a red background

Z-Translational Drive has a green background

Obtaining the Displacement-to-Phase part of the Transfer Function still produces difficulties -- I'm still working on the COMSOL-Matlab interface to perhaps better facilitate this.

RA: I have deleted those plots because they weren't transfer functions. Transfer functions must always be the ratio of something to something. For example: if I had a nickel for every bad plot I see, I would be a millionaire. In that example, the transfer function would have the units of nickels/plots. For the stacks, it should be meters/meter.

 

My apologies for the mislabeled axes on my previous plots. They have been corrected to a ratio (in./in.), as Rana so kindly suggested in his helpful, not-at-all-condescending response.

I have chosen to stay in the English system because all of the original stack drawings are in inches as well.

  4494   Wed Apr 6 19:36:32 2011 AidanSummaryGreen Locking(In)sanity check of Green PD - some inconsistencies

I moved the Hartmut Green PD to the Jenne laser bench to try to determine if the response at RF was reasonable or somehow very much smaller than it should be. It was set up as shown in the attached diagram. The first pass at this was by comparing the ratio of the RF photocurrent of the green PD to the RF photocurrent of the New Focus 1611 InGaAs PD. That ratio (at a sufficiently low frequency) should be the same as the ratio the DC photocurrents of the two PDs.

Using the network analyzer I measured the ratio of the voltages of the two RF signals (and then scaled each of these by the respective transimpedances of the PDs: 700 Ohms for the 1611 and 240 Ohms for the Harmut PD). The resulting ratio is shown in the attached plot.

I measured the DC voltages from each PD and scaled those by the transimpedances to get the photocurrent (10 kOhm for the 1611 and 80 Ohm effective for the Harmut PD). The ratio of the DC photocurrents was 0.37. This is roughly 3x the ratio of the RF photocurrents at 500kHz (=0.14). This discrepancy is uncomfortably large.

 The full set of measurements is given in the table below:

Measurement Value
DC voltage from Hartmut PD 6.5mV (checked by turning laser on and off and measuring the difference)
DC voltage from 1611 InGaAs PD 2.20V
Transimpedance of Harmut PD at DC 80 Ohm (effective)
Transimpedance of Harmut PD at RF 240 Ohm
Transimpedance of 1611 InGaAs at DC 10 KOhm
Transimpedance of 1611 InGaAs at RF 700 Ohm
Incident Power on Hartmut PD (100% on PD area) 0.28mW (measured by Ophir power meter)
Incident Power on 1611 InGaAs (<100% on PD area) 0.64mW
Responsivity of Silicon PD at 1064nm 0.02 A/W (estimate)
Responsivity of 1611 New Focus PD at 1064nm ~0.8 A/W
   

There is one other troubling point: using the estimate of responsivity on the Harmut PD * incident power * transimpedance at DC = (0.02A/W) * (0.28mW) * (80 V/A) = 0.45 mV.

But the measured DC voltage is 6.5mV = inconsistent.

Attachment 1: PD_measurement.png
PD_measurement.png
Attachment 2: plot_PD_RF_ratios.pdf
plot_PD_RF_ratios.pdf
  4500   Thu Apr 7 16:09:17 2011 AidanSummaryGreen Locking(In)sanity check of Green PD - some inconsistencies

I think I had underestimated the responsivity of the Silicon PD at 1064nm. The previous value was based on a rough search online for the responsivity of Silicon (I couldn't find the product number of the actual PD we are using). For instance, the PDA100A Si detector from Thorlabs has a responsivity of 0.35-0.4A/W at 1064nm. 

If we calculate the responsivity of the Hartmut PD from the measurements I made today (input power = 0.300mW, output voltage = 5.56mV, effective transimpedance = 80 Ohms), then the responsivity at 1064nm is 0.23 A/W which is not an unreasonable number given the response of the Thorlabs detector.

Quote:

Measurement Value
Responsivity of Silicon PD at 1064nm 0.02 A/W (estimate)
Responsivity of 1611 New Focus PD at 1064nm ~0.8 A/W
   

There is one other troubling point: using the estimate of responsivity on the Harmut PD * incident power * transimpedance at DC = (0.02A/W) * (0.28mW) * (80 V/A) = 0.45 mV.

But the measured DC voltage is 6.5mV = inconsistent.

 

  4501   Thu Apr 7 19:28:02 2011 KojiSummaryGreen Locking(In)sanity check of Green PD - some inconsistencies

Responsivity of SGD-444A

Quote:

For instance, the PDA100A Si detector from Thorlabs has a responsivity of 0.35-0.4A/W at 1064nm.

 

Attachment 1: SGD-444A.png
SGD-444A.png
  9854   Fri Apr 25 10:43:57 2014 KojiUpdateLSC(Fixed) Y end whitening board

I went to WB and found the last spare module of D990399 revB. We need to thank Frank for his foresight.

The original (=broken) board had various modifications from this revB.
I had to check the schemaric diagram and the difference between the boards and migrate some of the SMD components from left to right.


Here is the deciphered features of the QPD whitening board:
- The input stage is a VGA amp (AD602). It has the internal input impedance of 100 Ohm. The series resister
  of 909 Ohm gives us 1/10 voltage division! It is more tricky as the QPD (D990272) has the output impedances of 50Ohm
  (for the both side of the differential out) and on resistance of MAX333A. So it could have been deviated by ~10% from the nominal.

- Variable gain control: The input has 1/10 voltage division. The gain is fixed at the unity. In total the gain of the variable control stage is 1/10.
  This gives us the gain range of +42dB/-22dB for +10V/-10V. The actual range is limited to be -10~30dB.

- Whitening stages. Each channel has two sets of the whitening path and the bypass path.
  They could be switched by binary control inputs but I permanently enabled the whitening by pulling the MAX333 control inputs to the ground.
  The whitening zero and pole are at 4.02Hz and 40.6Hz.

  Each bypass path has an additional cap of 220pF in parallel to 35.7kOhm (R101 and R103 for CH1), resulting in the pole at 20.2kHz.
  Each whitening paths had a 5.6nF cap (C53 and C64). This cap was replaced with 350pF, resulting in the move of the pole freq from 800Hz to 12.7kHz.

- There are two anti-aliasing stages which were designed for 2kHz sampling rate. They are identical sallen key 2nd-order LPFs with fc=766Hz and Q=0.74 (~ butterworth).
  As all of these caps were removed, they are just voltage followers now.

- The final stage (AD620) has the gain resister of 16.5k. The gain is 1+(49.4k/16.5k) = 3.99.

- The 4pin lemo connector (J8) was removed from the board. We instead installed an isolated BNC connector on the panel for the thorlabs PD serving as the high gain PD.

- There is a daughter board for the high gain PD. This seems to be the butterworth low pass filter with fc=~30kHz.
  The differential output of the daughter board is connected to pin 17 and 18 of J10 (S5 Out and Rtn).

- The input of the daughter board is differential (AD620). Therefore the LEMO connectros next to the BNC were wrapped with Kapton tapes for isolation.

Board test at the workbench.

- The test required two dual power supply as the unit requires +/-5V and +/-15V.

- The four channels were tested with the signal injection. 1kHz input yielded 20mVpp across the AD602 input. The output of the 1st whitening stage was
  60mVpp. This makes sense as the gain of the AD620 is -10dB (1/10 and 10dB). The output of the 2nd whitening stage was 600mVpp.
  Finally the output of the output stage was confirmed to be 2400mVpp. This was confirmed for four channels.

- The daughter board output was also checked. The gain is the unity and flat upto ~10kHz.

Board installation

- Jenne installed the module. This time there was no smoke.


Gain mystery

- It was not sure how the whitening gains have been given.

- The corresponding database entry was found in /cvs/cds/caltech/target/c1auxey/ETMYaux.db as

grecord(ao,"C1:ASC-QPDY_S1WhiteGain")
grecord(ao,"C1:ASC-QPDY_S2WhiteGain")
grecord(ao,"C1:ASC-QPDY_S3WhiteGain")
grecord(ao,"C1:ASC-QPDY_S4WhiteGain")

- The gains for S2-S4 were set to be 30. However, C1:ASC-QPDY_S1WhiteGain was set to be 8.62068.
And it was not writable.

- After some investigation, it was found that the database was wrong. The DAC channel was changed from S100 to S0.
The corrected entry is shown here.

grecord(ao,"C1:ASC-QPDY_S1WhiteGain")
{
        field(DESC,"Whitening gain for QPDY Seg 1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C0 S0 @")
        field(PREC,"1")
        field(EGUF,"42")
        field(EGUL,"-22")
        field(EGU,"dB")
        field(LINR,"LINEAR")
        field(DRVH,"30")
        field(DRVL,"-10")
        field(HOPR,"30")
        field(LOPR,"-10")
}

- Once c1auxey was rebooted, the S1 whitening gain became writable. Now all of the channels were set to be +30dB (max).

 

Attachment 1: D990399-B_40m.pdf
D990399-B_40m.pdf D990399-B_40m.pdf D990399-B_40m.pdf
Attachment 2: P4245552.JPG
P4245552.JPG
Attachment 3: P4245553.JPG
P4245553.JPG
Attachment 4: P4245551.JPG
P4245551.JPG
  10785   Thu Dec 11 18:12:46 2014 ericqUpdateLSC(Fixed) Y end whitening board

Quote:

Gain mystery

- It was not sure how the whitening gains have been given.

- The corresponding database entry was found in /cvs/cds/caltech/target/c1auxey/ETMYaux.db as

grecord(ao,"C1:ASC-QPDY_S1WhiteGain")
grecord(ao,"C1:ASC-QPDY_S2WhiteGain")
grecord(ao,"C1:ASC-QPDY_S3WhiteGain")
grecord(ao,"C1:ASC-QPDY_S4WhiteGain")

- The gains for S2-S4 were set to be 30. However, C1:ASC-QPDY_S1WhiteGain was set to be 8.62068.
And it was not writable.

- After some investigation, it was found that the database was wrong. The DAC channel was changed from S100 to S0.
The corrected entry is shown here.

grecord(ao,"C1:ASC-QPDY_S1WhiteGain")
{
        field(DESC,"Whitening gain for QPDY Seg 1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C0 S0 @")
        field(PREC,"1")
        field(EGUF,"42")
        field(EGUL,"-22")
        field(EGU,"dB")
        field(LINR,"LINEAR")
        field(DRVH,"30")
        field(DRVL,"-10")
        field(HOPR,"30")
        field(LOPR,"-10")
}

- Once c1auxey was rebooted, the S1 whitening gain became writable. Now all of the channels were set to be +30dB (max). 

This exact situation was happening at ETMX. I did the exact same change to the database, now I can read and write all four gain segments.

  2065   Wed Oct 7 19:23:49 2009 JenneUpdateAdaptive Filtering(Final?) PEM cabling changes

Quote:

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

 I spiffed up the order of the cables / sensors plugged into the PEM ADCU.  Now all of the seismometers are labeled as Rana left them, and the 2 Guralp's have their sets of 3 channels next to eachother in channel-number-land.  None of the accelerometer names/cabling have changed recently.  In the table, Cable-label refers to the physical tag tied to the end of the cables plugged into the ADCU...they are meant to be descriptive of what seismometer channels they are hooked up to, and then the names change to something useful for us when they come into the DAQ system.  Also, the labels of input channels on the ASS_TOP_PEM screen have been updated accordingly.

 

Channel Name Channel Number on ADCU and OAF PEM list Cable-label .ini channel number
C1:SEIS-GUR2_X 2 Gur2 EW 15001
C1:SEIS-GUR2_Y 3 Gur2 NS 15002
C1:SEIS-GUR2_Z 4 Gur2 Vert 15003
C1:SEIS-GUR1_X 10 Gur1 EW 15009
C1:SEIS-GUR1_Y 11 Gur1 NS 15010
C1:SEIS-GUR1_Z 12 Gur1 Vert 15011
C1:SEIS-RANGER_Y 24 Ranger

15023

 

  4631   Thu May 5 00:08:59 2011 JenneUpdateLSC(Almost) New Screens for RFPDs

I modified C1LSC.mdl to use the CDSphase blocks, which automatically calculate the R and D phase rotation for us.  Now each of the RFPDs has 2 channels in place of the old IQ_MTRX channels:  C1:LSC-RFPD_PHASE_R and C1:LSC-RFPD_PHASE_D.

I have not yet compiled / rebooted / done CDS magic to actually make these installed.  So far the change is only in the simulink model.

I was going to wait until morning to compile/reboot/magic, so I can do it under Joe's supervision.

In the meantime, I also modified the RFPD screens.  They have white boxes for the _R and _D channels just now, but that's because the new model hasn't been put in.  They now look like phase rotators, instead of Koji's temporary matrix.

Still to do:  Find the EPICS database where the phase rotation calculation is done (you give it an angle, it gives you sin(angle) and cos(angle) ).  I want to put a "90-angle" in the database so that we can type in the measured relative phase between I and Q, and it will calculate how many more degrees it needs to get to 90deg. 

 

  2745   Wed Mar 31 19:29:58 2010 HartmutUpdateElectronics(1cm-) Si PD transfer functions update

Recorded transfer functions for the 1cm Si-PD as described on p. 2708

for different biases. I put the plots in there, to keep the info in one place,

where the label on the PD case (which Steve made without asking him) points

to.

I talked to some people recently about the fact that the responsivity (A/W) of the PD

changes even at DC for different biases. I tested this again and should be more precise about this:

The first time I observed this was in the transfer functions as shown on p. 2708.

With 'DC' I meant 'low frequency' there, as you can still see an effect of the bias as low as 100kHz.

Then at one point I saw the responsivity changing with bias also at true DC.

However, it turned out that this is only the case if the photocurrent is too high.

If the photocurrent is 4mA, you need 400mV bias to get the max. responsivity.

For 2mA photocurrent, the responsivity is already maximal for 0V bias.

An effect for relative low frequencies remains however.

The DC check of responsivity was done with white light from a bulb.

 

 

  9289   Fri Oct 25 04:03:40 2013 MasayukiUpdateLSC'scope and spectrum analyser for REFL165

As Jenne's Elog we want to see Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if the signal is saturated while bring the arms into resonance.
I started to connect the spectrum analyser and the 'scope to REFL165 output.

Directional coupler (Mini=-circuits ZMDC-10-2 ZMDC-20-3) was connected just before the dimod boad input. The main output of coupler is plugged into demod board's input.The other output of the coupler is connected to AG4395A using BNC cable.

The spectrum analyser output can be read using netgpibdata in control room. The IP address is 192.168.113.108 and the GPIB address is 17. For this I dissconected the network hub from another AG4395A, which is at the front of 1X2 lack.

I didn't connected the 300 MHz 'scope right now, but tomorrow it will be connected using power splitter and also be able to get data by internet. For connect 'scope to network, I disconected the network hub from SR785.

ELOG V3.1.3-