40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 290 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  1551   Wed May 6 16:56:35 2009 rana, alex, joeConfigurationComputersdaqd log, cront, etc.
While Alex came over, we investigated the log file problems with DAQD and NDS on FB0. There was a lot of
the standard puzzling and mumbling, but eventually we saw that it doesn't create its log file and so it
doesn't write to it. The log file is /usr/controls/main_daqd.log. The other files called daqd.log.DATE
in the logs/ directory are actually not written to. Its awesome.

We also have put in a fix for the overflowing jobs/ directory. It gets a file written to it every time
you make and NDS request and our seisBLRMS has been overloading it. There's now a cron for it in the fb0
crontab which cleans out week-old files at 6:30 AM every day.

We also changed the time of the daily backup from 3:30 AM (when people are still working) to 5:50 AM
(by which time the seismic has ramped up and interferometerists should be asleep). I didn't like the
idea of a bandwidth hog nailing the framebuilder during the peak of interferometer work.

#
# Script to backup via rsync the most recent 40m minute trends and
# any changes to the /cvs/cds filesystem.
#
50 05 * * * /cvs/cds/caltech/scripts/backup/rsync.backup < /dev/null > /cvs/cds/caltech/scripts/\
backup/rsync.backup.log 2>&1

30 06 * * * find /usr/controls/jobs -mtime +7 -exec /bin/rm -f {} \;

seisBLRMS.m restarted on mafalda.
  9530   Tue Jan 7 22:44:45 2014 JenneUpdateCDSdaqd on fb is segfaulting every ~30 seconds

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!

Here is a screen dump from the "dtail":

Every 1.0s: dmesg | tail -50                                                                                                                         Tue Jan  7 22:43:23 2014

[   33.498691]  [<ffffffff8104a063>] kthread+0x7a/0x82
[   33.498695]  [<ffffffff81003654>] kernel_thread_helper+0x4/0x10
[   33.498698]  [<ffffffff81049fe9>] ? kthread+0x0/0x82
[   33.498701]  [<ffffffff81003650>] ? kernel_thread_helper+0x0/0x10
[   33.498703] ---[ end trace 6236defa99b3e091 ]---
[   33.498705] mx INFO: Board 0: allocated MSI IRQ 67
[   33.498713] mx INFO: CPU0: PAT = 0x7010600070106
[   33.498715] mx INFO: CPU0: new PAT = 0x1010600070106
[   33.498718] mx INFO: Board 0: Using PAT index 6
[   33.499101] eth0: no IPv6 routers present
[   33.531013] mx INFO: Board 0: device 8, rev 0, 1 ports and 2096896 bytes of SRAM available
[   33.531017] mx INFO: Board 0: Bridge is 10de:005d
[   33.531228] mx INFO: Board 0: MAC address = 00:60:dd:46:ea:ec
[   33.535971] mx INFO: Loaded mcp of len 235448
[   34.489244] mx INFO: Starting usermode mapper at /opt/mx/sbin/mx_start_mapper
[   39.148855] mx INFO: mx0: Link0 is UP
[   39.588511] mx INFO: myri0: Will use skbuf frags (4096 bytes, order=0)
[   39.589299] mx INFO: 1 Myrinet board found and initialized
[  287.706367] daqd used greatest stack depth: 3368 bytes left
[86605.907520] daqd[18407]: segfault at 38b08e4c0 ip 00007f11b3942a6c sp 00007f10b1917d50 error 4
[86605.907530] daqd[18424]: segfault at 38b544f90 ip 00007f11b3942a6c sp 00007f10b12c6d30 error 4 in libc-2.10.1.so[7f11b390e000+14c000] in libc-2.10.1.so[7f11b390e000+14c00
0]
[86605.907544]
[86605.919454] daqd[21319] general protection ip:7f11b3942a6c sp:7f10b1814d30 error:0
[86605.919462] daqd[18442] general protection ip:7f11b3942a6c sp:7f10b0bf4d30 error:0
[86605.919615] daqd[18443]: segfault at 38aee3db0 ip 00007f11b3942a6c sp 00007f10b0b73d50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919694] daqd[18412]: segfault at 38aff35d0 ip 00007f11b3942a6c sp 00007f10b1752d30 error 4
[86605.919701] daqd[18417]: segfault at 38b544f70 ip 00007f11b3942a6c sp 00007f10b154dd50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919708] daqd[18445]: segfault at 38aff35b0 ip 00007f11b3942a6c sp 00007f10b0ab1d50 error 4
[86605.919733] daqd[18429]: segfault at 38b42ae90 ip 00007f11b3942a6c sp 00007f10b10c1d50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919741] daqd[18440]: segfault at 38b08e480 ip 00007f11b3942a6c sp 00007f10b0cb6d30 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958551]  in libc-2.10.1.so[7f11b390e000+14c000] in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958557]
[86605.958577]  in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958586]  in libc-2.10.1.so[7f11b390e000+14c000]
[86605.959639] daqd used greatest stack depth: 3160 bytes left
[98139.100888] show_signal_msg: 13 callbacks suppressed
[98139.100895] daqd[23753]: segfault at 39c7363b0 ip 00007f5bf253ba6c sp 00007f5b69b48d30 error 4 in libc-2.10.1.so[7f5bf2507000+14c000]
[98687.815120] daqd used greatest stack depth: 2984 bytes left
[208995.594227] daqd[10386] general protection ip:7f3b7c930a6c sp:7f3a79f09d50 error:0 in libc-2.10.1.so[7f3b7c8fc000+14c000]
[353015.067479] daqd used greatest stack depth: 2880 bytes left
[367406.863618] daqd[13078]: segfault at 41 ip 0000000000000041 sp 00007fb1f0ba2cf8 error 14 in daqd[400000+7c000]
[367406.863833] daqd[13104] general protection ip:7fb2f3018a6c sp:7fb1f01c8d30 error:0
[367406.863877] daqd[13086] general protection ip:7fb2f3018a6c sp:7fb1f089ad30 error:0
[367406.877408] daqd[13080]: segfault at 41 ip 0000000000000041 sp 00007fb1f0ae0ca8 error 14 in daqd[400000+7c000]
[367406.877435]  in libc-2.10.1.so[7fb2f2fe4000+14c000]
[367406.877442] daqd[13100]: segfault at 39ba287b0 ip 00007fb2f3018a6c sp 00007fb1f034cd30 error 4 in libc-2.10.1.so[7fb2f2fe4000+14c000]
[367406.878372]  in libc-2.10.1.so[7fb2f2fe4000+14c000]
[399802.887523] daqd[18295] general protection ip:7fb056a71a6c sp:7faf96125f10 error:0 in libc-2.10.1.so[7fb056a3d000+14c000]
[410595.969327] daqd[22057]: segfault at 3a91f27b0 ip 00007f48e96eea6c sp 00007f47e6c26d50 error 4 in libc-2.10.1.so[7f48e96ba000+14c000]
[410595.988926] daqd[22068]: segfault at 3a91f2790 ip 00007f48e96eea6c sp 00007f47e681bd30 error 4 in libc-2.10.1.so[7f48e96ba000+14c000]

  7105   Tue Aug 7 15:04:23 2012 JamieUpdateCDSdaqd problem was root-owned files and directories

Apparently the last problem was because of root-owned frame directories that daqd was trying to write to.  During debugging Alex had run daqd as root, but it's supposed to run as controls.  All the /frame directories are supposed to be owned by controls.  When daqd was run as root, it created new frame directories owned by root, which controls couldn't write to when I restarted daqd the proper way.  Once we chown'd the directories daqd started running again.

Alex also put in a "fix" for the core dump problem.  He touched an empty core file owned by root:

-rw-r--r-- 1 root root 0 Aug  7 14:38 /opt/rtcds/caltech/c1/target/fb/core

This will prevent any dying daqd process owned by controls from dumping it's core at that location.  Personally I think this is a horribly hacky "solution" that doesn't actually fix any of the issues that were causing the segfaults to begin with, but it might prevent some of the network slow down we see when the core does dump.  It's mostly just masking the problem, though, so I'm tempted to remove it so we all feel the pain when daqd starts shitting all over the network again.

  6106   Mon Dec 12 13:02:08 2011 kiwamuUpdateCDSdaqd restarted

I have restarted the daqd process at 1:01 PM since I have added some new ALS's daq channels.

  7102   Tue Aug 7 14:17:07 2012 JamieUpdateCDSdaqd running again; related to c1sup issue

So daqd's problem was apparently the bad/non-running c1sup model.  The c1sup model, which I reported on attempting to get running in 7097, was not running because there were no available CPUs on the c1sus FE machine.  This was due to my stupid undercounting of the number of CPUs.  Anyway, for reasons I don't understand, this was causing daqd to segfault.  Removing c1sup from c1sus "fixed" the problem.

Alex agreed that daqd should definitely not be segfaulting in this circumstance.  It's still unclear exactly what daqd was looking at that was causing it to crash.

I'm going to move c1sup to c1iscex, which has a lot of spare CPUs.

  7096   Mon Aug 6 20:22:50 2012 JamieUpdateCDSdaqd segfaulting after five minutes

I tried running daqd manually, and sure enough it segfaults after about five minutes (see log below).  I've uncommented it from /etc/inittab on fb and I'm leaving it off for now until we can figure out what's going on.

controls@fb /opt/rtcds/caltech/c1/target/fb 0$ /opt/rtcds/caltech/c1/target/fb/daqd -c /opt/rtcds/caltech/c1/target/fb/daqdrc
263596
MX endpoint opened
startup file interpreter thread tid=139790943115536
calling yyparse(5, 6)
[Mon Aug  6 20:15:27 2012] ->5: #set avoid_reconnect
[Mon Aug  6 20:15:27 2012] ->5: set thread_stack_size=102400
[Mon Aug  6 20:15:27 2012] new threads will be created with the stack of size 102400K
[Mon Aug  6 20:15:27 2012] ->5: set allow_tpman_connect_fail
[Mon Aug  6 20:15:27 2012] ->5: #set dcu_status_check=5
[Mon Aug  6 20:15:27 2012] ->5: #set symm_gps_offset=-1
[Mon Aug  6 20:15:27 2012] ->5: #set symm_gps_offset=31535998
[Mon Aug  6 20:15:27 2012] ->5: ##set symm_gps_offset=347155213
[Mon Aug  6 20:15:27 2012] ->5: #set symm_gps_offset=378691215
[Mon Aug  6 20:15:27 2012] ->5: #set symm_gps_offset=378691212
[Mon Aug  6 20:15:27 2012] ->5: #set symm_gps_offset=315964799
[Mon Aug  6 20:15:27 2012] ->5: set symm_gps_offset=315964801
[Mon Aug  6 20:15:27 2012] ->5: set debug=0
[Mon Aug  6 20:15:27 2012] ->5: set log=2
[Mon Aug  6 20:15:27 2012] ->5: set zero_bad_data=0
[Mon Aug  6 20:15:27 2012] ->5: set dcu_status_check=9
[Mon Aug  6 20:15:27 2012] ->5: set controller_dcu=33
[Mon Aug  6 20:15:27 2012] ->5: set master_config="/opt/rtcds/caltech/c1/target/fb/master"
[Mon Aug  6 20:15:30 2012] finished configuring data channels
[Mon Aug  6 20:15:30 2012] ->5: configure channels begin end
GDS server NODE=19 HOST=c1iscex DCUID=19
GDS server NODE=20 HOST=c1sus DCUID=20
GDS server NODE=21 HOST=c1sus DCUID=21
GDS server NODE=22 HOST=c1lsc DCUID=22
GDS server NODE=25 HOST=c1iscex DCUID=61
GDS server NODE=28 HOST=c1ioo DCUID=28
GDS server NODE=33 HOST=c1ioo DCUID=33
GDS server NODE=34 HOST=c1ioo DCUID=34
GDS server NODE=36 HOST=c1sus DCUID=36
GDS server NODE=38 HOST=c1sus DCUID=38
GDS server NODE=39 HOST=c1sus DCUID=39
GDS server NODE=40 HOST=c1lsc DCUID=40
GDS server NODE=42 HOST=c1lsc DCUID=42
GDS server NODE=45 HOST=c1iscex DCUID=45
GDS server NODE=46 HOST=c1iscey DCUID=46
GDS server NODE=47 HOST=c1iscey DCUID=47
GDS server NODE=48 HOST=c1lsc DCUID=48
GDS server NODE=50 HOST=c1lsc DCUID=50
GDS server NODE=51 HOST=c1ioo DCUID=51
GDS server NODE=60 HOST=c1lsc DCUID=60
GDS server NODE=61 HOST=c1iscex DCUID=61
GDS server NODE=62 HOST=c1sus DCUID=62
Unable to find GDS node 90 system c1x00 in INI files
GDS server NODE=91 HOST=c1lsc DCUID=60
Unable to find GDS node 92 system c1tst2 in INI files
Unable to find GDS node 95 system c1x10 in INI files
TP: node = 19, host = c1iscex, dup = 0, prog = 0x31002013, vers = 1
Initialized TP interface node=19, host=c1iscex
TP: node = 20, host = c1sus, dup = 0, prog = 0x31002014, vers = 1
Initialized TP interface node=20, host=c1sus
TP: node = 21, host = c1sus, dup = 0, prog = 0x31002015, vers = 1
Initialized TP interface node=21, host=c1sus
TP: node = 22, host = c1lsc, dup = 0, prog = 0x31002016, vers = 1
Initialized TP interface node=22, host=c1lsc
TP: node = 25, host = c1iscex, dup = 0, prog = 0x31002019, vers = 1
Initialized TP interface node=25, host=c1iscex
TP: node = 28, host = c1ioo, dup = 0, prog = 0x3100201c, vers = 1
Initialized TP interface node=28, host=c1ioo
TP: node = 33, host = c1ioo, dup = 0, prog = 0x31002021, vers = 1
Initialized TP interface node=33, host=c1ioo
TP: node = 34, host = c1ioo, dup = 0, prog = 0x31002022, vers = 1
Initialized TP interface node=34, host=c1ioo
TP: node = 36, host = c1sus, dup = 0, prog = 0x31002024, vers = 1
Initialized TP interface node=36, host=c1sus
TP: node = 38, host = c1sus, dup = 0, prog = 0x31002026, vers = 1
Initialized TP interface node=38, host=c1sus
TP: node = 39, host = c1sus, dup = 0, prog = 0x31002027, vers = 1
Initialized TP interface node=39, host=c1sus
TP: node = 40, host = c1lsc, dup = 0, prog = 0x31002028, vers = 1
Initialized TP interface node=40, host=c1lsc
TP: node = 42, host = c1lsc, dup = 0, prog = 0x3100202a, vers = 1
Initialized TP interface node=42, host=c1lsc
TP: node = 45, host = c1iscex, dup = 0, prog = 0x3100202d, vers = 1
Initialized TP interface node=45, host=c1iscex
TP: node = 46, host = c1iscey, dup = 0, prog = 0x3100202e, vers = 1
Initialized TP interface node=46, host=c1iscey
TP: node = 47, host = c1iscey, dup = 0, prog = 0x3100202f, vers = 1
Initialized TP interface node=47, host=c1iscey
TP: node = 48, host = c1lsc, dup = 0, prog = 0x31002030, vers = 1
Initialized TP interface node=48, host=c1lsc
TP: node = 50, host = c1lsc, dup = 0, prog = 0x31002032, vers = 1
Initialized TP interface node=50, host=c1lsc
TP: node = 51, host = c1ioo, dup = 0, prog = 0x31002033, vers = 1
Initialized TP interface node=51, host=c1ioo
TP: node = 60, host = c1lsc, dup = 0, prog = 0x3100203c, vers = 1
Initialized TP interface node=60, host=c1lsc
TP: node = 61, host = c1iscex, dup = 0, prog = 0x3100203d, vers = 1
Initialized TP interface node=61, host=c1iscex
TP: node = 62, host = c1sus, dup = 0, prog = 0x3100203e, vers = 1
Initialized TP interface node=62, host=c1sus
TP: node = 91, host = c1lsc, dup = 0, prog = 0x3100205b, vers = 1
Initialized TP interface node=91, host=c1lsc
[Mon Aug  6 20:15:30 2012] ->5: tpconfig "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par"
[Mon Aug  6 20:15:30 2012] ->5: set gps_leaps = 820108813
[Mon Aug  6 20:15:30 2012] ->5: set detector_name="CIT"
[Mon Aug  6 20:15:30 2012] ->5: set detector_prefix="C1"
[Mon Aug  6 20:15:30 2012] ->5: set detector_longitude=-90.7742403889
[Mon Aug  6 20:15:30 2012] ->5: set detector_latitude=30.5628943337
[Mon Aug  6 20:15:30 2012] ->5: set detector_elevation=.0
[Mon Aug  6 20:15:30 2012] ->5: set detector_azimuths=1.1,4.7123889804
[Mon Aug  6 20:15:30 2012] ->5: set detector_altitudes=1.0,2.0
[Mon Aug  6 20:15:30 2012] ->5: set detector_midpoints=2000.0, 2000.0
[Mon Aug  6 20:15:30 2012] ->5: set num_dirs = 10
[Mon Aug  6 20:15:30 2012] ->5: set frames_per_dir=225
[Mon Aug  6 20:15:30 2012] ->5: set full_frames_per_file=1
[Mon Aug  6 20:15:30 2012] ->5: set full_frames_blocks_per_frame=16
[Mon Aug  6 20:15:30 2012] ->5: set frame_dir="/frames/full", "C-R-", ".gwf"
[Mon Aug  6 20:15:30 2012] ->5: set trend_num_dirs=10
[Mon Aug  6 20:15:30 2012] ->5: set trend_frames_per_dir=1440
[Mon Aug  6 20:15:30 2012] ->5: set trend_frame_dir= "/frames/trend/second", "C-T-", ".gwf"
[Mon Aug  6 20:15:30 2012] ->5: set raw-minute-trend-dir="/frames/trend/minute_raw"
[Mon Aug  6 20:15:30 2012] ->5: set nds-jobs-dir="/opt/rtcds/caltech/c1/target/fb"
[Mon Aug  6 20:15:30 2012] ->5: set minute-trend-num-dirs=10
[Mon Aug  6 20:15:30 2012] ->5: set minute-trend-frames-per-dir=24
[Mon Aug  6 20:15:30 2012] ->5: set minute-trend-frame-dir="/frames/trend/minute", "C-M-", ".gwf"
[Mon Aug  6 20:15:30 2012] ->5: start main 10
Allocated move buffer size 11616356 bytes
[Mon Aug  6 20:15:32 2012] main started
[Mon Aug  6 20:15:32 2012] ->5: start profiler
[Mon Aug  6 20:15:32 2012] ->5: # comment out this block to stop saving data
[Mon Aug  6 20:15:32 2012] frame saver started
[Mon Aug  6 20:15:32 2012] ->5: start frame-saver
[Mon Aug  6 20:15:33 2012] ->5: sync frame-saver
[Mon Aug  6 20:15:33 2012] ->5: start trender
[Mon Aug  6 20:15:33 2012] trender started
[Mon Aug  6 20:15:33 2012] trend frame saver started
[Mon Aug  6 20:15:33 2012] ->5: start trend-frame-saver
[Mon Aug  6 20:15:34 2012] ->5: sync trend-frame-saver
[Mon Aug  6 20:15:34 2012] minute trend frame saver started
[Mon Aug  6 20:15:34 2012] ->5: start minute-trend-frame-saver
[Mon Aug  6 20:15:34 2012] Done creating ADC structures
[Mon Aug  6 20:15:35 2012] ->5: sync minute-trend-frame-saver
[Mon Aug  6 20:15:35 2012] raw minute trend frame saver started
[Mon Aug  6 20:15:35 2012] ->5: start raw_minute_trend_saver
[Mon Aug  6 20:15:35 2012] ->5: #frame-writer "225.225.225.1" broadcast="131.215.113.0" all
[Mon Aug  6 20:15:35 2012] ->5: #sleep 5
[Mon Aug  6 20:15:35 2012] producer started
[Mon Aug  6 20:15:35 2012] ->5: start producer
[Mon Aug  6 20:15:35 2012] ->5: start epics dcu
[Mon Aug  6 20:15:35 2012] MX receiver thread started
[Mon Aug  6 20:15:35 2012] edcu started
[Mon Aug  6 20:15:35 2012] ->5: start epics server "C0:DAQ-DC0_" "C1:DAQ-DC0_"
[Mon Aug  6 20:15:35 2012] epics server started
[Mon Aug  6 20:15:35 2012] ->5: start listener 8087
[Mon Aug  6 20:15:35 2012] ->5: start listener 8088 1
[Mon Aug  6 20:15:35 2012] ->5: sleep 60
Creating C1:DAQ-DC0_PEM_SLOW_STATUS
Creating C1:DAQ-DC0_PEM_SLOW_CRC_CPS
Creating C1:DAQ-DC0_PEM_SLOW_CRC_SUM
Creating C1:DAQ-DC0_C1X01_STATUS
Creating C1:DAQ-DC0_C1X01_CRC_CPS
Creating C1:DAQ-DC0_C1X01_CRC_SUM
Creating C1:DAQ-DC0_C1X02_STATUS
Creating C1:DAQ-DC0_C1X02_CRC_CPS
Creating C1:DAQ-DC0_C1X02_CRC_SUM
Creating C1:DAQ-DC0_C1SUS_STATUS
Creating C1:DAQ-DC0_C1SUS_CRC_CPS
Creating C1:DAQ-DC0_C1SUS_CRC_SUM
Creating C1:DAQ-DC0_C1OAF_STATUS
Creating C1:DAQ-DC0_C1OAF_CRC_CPS
Creating C1:DAQ-DC0_C1OAF_CRC_SUM
Creating C1:DAQ-DC0_C1ALS_STATUS
Creating C1:DAQ-DC0_C1ALS_CRC_CPS
Creating C1:DAQ-DC0_C1ALS_CRC_SUM
Creating C1:DAQ-DC0_C1X03_STATUS
Creating C1:DAQ-DC0_C1X03_CRC_CPS
Creating C1:DAQ-DC0_C1X03_CRC_SUM
Creating C1:DAQ-DC0_C1IOO_STATUS
Creating C1:DAQ-DC0_C1IOO_CRC_CPS
Creating C1:DAQ-DC0_C1IOO_CRC_SUM
Creating C1:DAQ-DC0_C1MCS_STATUS
Creating C1:DAQ-DC0_C1MCS_CRC_CPS
Creating C1:DAQ-DC0_C1MCS_CRC_SUM
Creating C1:DAQ-DC0_C1RFM_STATUS
Creating C1:DAQ-DC0_C1RFM_CRC_CPS
Creating C1:DAQ-DC0_C1RFM_CRC_SUM
Creating C1:DAQ-DC0_C1PEM_STATUS
Creating C1:DAQ-DC0_C1PEM_CRC_CPS
Creating C1:DAQ-DC0_C1PEM_CRC_SUM
Creating C1:DAQ-DC0_C1X04_STATUS
Creating C1:DAQ-DC0_C1X04_CRC_CPS
Creating C1:DAQ-DC0_C1X04_CRC_SUM
Creating C1:DAQ-DC0_C1LSC_STATUS
Creating C1:DAQ-DC0_C1LSC_CRC_CPS
Creating C1:DAQ-DC0_C1LSC_CRC_SUM
Creating C1:DAQ-DC0_C1SCX_STATUS
Creating C1:DAQ-DC0_C1SCX_CRC_CPS
Creating C1:DAQ-DC0_C1SCX_CRC_SUM
Creating C1:DAQ-DC0_C1X05_STATUS
Creating C1:DAQ-DC0_C1X05_CRC_CPS
Creating C1:DAQ-DC0_C1X05_CRC_SUM
Creating C1:DAQ-DC0_C1SCY_STATUS
Creating C1:DAQ-DC0_C1SCY_CRC_CPS
Creating C1:DAQ-DC0_C1SCY_CRC_SUM
Creating C1:DAQ-DC0_C1ASS_STATUS
Creating C1:DAQ-DC0_C1ASS_CRC_CPS
Creating C1:DAQ-DC0_C1ASS_CRC_SUM
Creating C1:DAQ-DC0_C1CAL_STATUS
Creating C1:DAQ-DC0_C1CAL_CRC_CPS
Creating C1:DAQ-DC0_C1CAL_CRC_SUM
Creating C1:DAQ-DC0_C1MCC_STATUS
Creating C1:DAQ-DC0_C1MCC_CRC_CPS
Creating C1:DAQ-DC0_C1MCC_CRC_SUM
Creating C1:DAQ-DC0_C1MCP_STATUS
Creating C1:DAQ-DC0_C1MCP_CRC_CPS
Creating C1:DAQ-DC0_C1MCP_CRC_SUM
Creating C1:DAQ-DC0_C1LSP_STATUS
Creating C1:DAQ-DC0_C1LSP_CRC_CPS
Creating C1:DAQ-DC0_C1LSP_CRC_SUM
Creating C1:DAQ-DC0_C1SPX_STATUS
Creating C1:DAQ-DC0_C1SPX_CRC_CPS
Creating C1:DAQ-DC0_C1SPX_CRC_SUM
Creating C1:DAQ-DC0_C1SUP_STATUS
Creating C1:DAQ-DC0_C1SUP_CRC_CPS
Creating C1:DAQ-DC0_C1SUP_CRC_SUM
[Mon Aug  6 20:15:35 2012] Epics server started
[Mon Aug  6 20:15:35 2012] EDCU has 2553 channels configured; first=0

Symmetricom status: LOCKED
Starting at gps 1028344552 prev_gps 1028344552 frac 312500000 f 314094022
[Mon Aug  6 20:15:38 2012] Minute trender made GPS time correction; gps=1028344552; gps%60=52
Segmentation fault (core dumped)

  13145   Wed Jul 26 19:13:07 2017 JamieUpdateCDSdaqd showing same instability as before

I recompiled daqd on the updated fb1, similar to how I had before, and we're seeing the same instability: process crashes when it tries to write out the second trend (technically it looks like it crashes while it's trying to write out the full frame while the second trend is also being written out).  Jonathan Hanks and I are actively looking into it and i'll provide further report soon.

  13176   Wed Aug 9 12:05:57 2017 ranaUpdateElectronicsdata archiving

This kind of data fitting and analysis is really useful. We should figure out a way to archive it. Perhaps the data files and fitting stuff can be put into GIT in some smart way? The fit results can be added to the 40m MC electronics DCC tree. Then the links can be added to this elog.

  14723   Wed Jul 3 23:53:38 2019 MilindUpdateCamerasdata for nns

Tried collecting data today. Was unable to keep the camera_server code running for any length of time as it threw segfaults. Will take a shot again tomorrow.

Quote:

The GigE is focused now (judged by eye) and I have closed the lid. I'm attaching a picture of the MC2 beam spot, captured using GigE at an exposure time of 400µs.

What was the solution to resolving the flaky video streaming during the alignment process????

-> I think, the issue was with either the poor wireless network conection or the GigE-PoE ethernet cable.

Quote:

Turns out, focusing the GigE is actually a bit tricky. With pylon, everytime I change the exposure or the focus, I'm running into the error I had mentioned earlier in one of my elogs; so I tried using the python scripts to interact with the GigE. But whenever I try to change the focal plane distance by rotating the lens coupler, the ethernet cable connection becomes loose and the camera server needs to be relaunched every now and then. Also, everytime we want to change the distance between the lenses, the telescope needs to be dismantled and refocused again. I'll try to come up with a better telescope design for this.

Yesterday, I had focused the GigE using a low exposure time and small aperture of iris, to make sure that we are actually seeing a sharp image of the beam spot. I'm attaching a picture of the beam spot I had clicked while focusing it, unfortunately, I forgot to take a picture after I had focused it completely. I'm also attaching a picture of the final setup for future reference. 


Yesterday night, Rana asked me to lock the MC2. I figured that the PSL shutter was closed; I just opened it and was able to see the beam spot on the analog camera screen.

  5184   Thu Aug 11 08:29:28 2011 steveUpdateComputersdataviewer at Rosalba

I'm having this problem with DTV every morning at Rosalba only. It wants to start with a negative GPS time and it can not connect to the frame builder.

Normally after a few time of starting it, it will work.

  4881   Fri Jun 24 22:35:23 2011 ranaConfigurationCDSdataviewer broken on pianosa

When I try to get minute trend, it says "word too long".

  13165   Thu Aug 3 20:15:11 2017 JamieUpdateCDSdataviewer can not raise test points

For some reason dataviewer is not able to raise test points with the new daqd setup, even though dtt can.  If you raise a test point with dtt then dataviewer can show the data fine.

It's unclear to me why this would be the case.  It might be that all the versions of dataviewer on the workstations are too old??  I'll look into it tomorrow to see if I can figure out what's going on.

  5895   Tue Nov 15 15:16:04 2011 kiwamuUpdateCDSdataviewer doesn't run

Dataviewer is not able to access to fb somehow.

I restarted daqd on fb but it didn't help.

Also the status screen is showing a blank white form in all the realtime model. Something bad is happening.

blank.png

JAMIEEEE !!!!

  5896   Tue Nov 15 15:56:23 2011 jamieUpdateCDSdataviewer doesn't run

Quote:

Dataviewer is not able to access to fb somehow.

I restarted daqd on fb but it didn't help.

Also the status screen is showing a blank while form in all the realtime model. Something bad is happening.

 So something very strange was happening to the framebuilder (fb).  I logged on the fb and found this being spewed to the logs once a second:

[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory

Apparently /bin/gcore was trying to be called by some daqd subprocess or thread, and was failing since that file doesn't exist.  This apparently started at around 5:52 AM last night:

[Tue Nov 15 05:46:52 2011] main profiler warning: 1 empty blocks in the buffer
[Tue Nov 15 05:46:53 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:46:54 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:46:55 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:46:56 2011] main profiler warning: 0 empty blocks in the buffer
...
[Tue Nov 15 05:52:43 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:52:44 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:52:45 2011] main profiler warning: 0 empty blocks in the buffer
GPS time jumped from 1005400026 to 1005400379
[Tue Nov 15 05:52:46 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 05:52:46 2011] going down on signal 11
sh: /bin/gcore: No such file or directory

The gcore I believe it's looking for is a debugging tool that is able to retrieve images of running processes.  I'm guessing that something caused something int the fb to eat crap, and it was stuck trying to debug itself.  I can't tell what exactly happend, though.  I'll ping the CDS guys about it.  The daqd process was continuing to run, but it was not responding to anything, which is why it could not be restarted via the normal means, and maybe why the various FB0_*_STATUS channels were seemingly dead.

I manually killed the daqd process, and monit seemed to bring up a new process with no problem.  I'll keep an eye on it.

  7758   Wed Nov 28 21:42:21 2012 ranaFrogsComputer Scripts / Programsdataviewer font error

An error this evening on rossa: dataviewer not working due to some font errors:

controls@rossa:~ 0$ dataviewer
Connecting.... done
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning:
    Name: FilterText
    Class: XmTextField
    Character '\52' not supported in font.  Discarded.

Warning:
    Name: FilterText
    Class: XmTextField
    Character '\56' not supported in font.  Discarded.

Warning:
    Name: FilterText
    Class: XmTextField
    Character '\170' not supported in font.  Discarded.

Warning:

etc.............

  13181   Thu Aug 10 09:10:55 2017 steveUpdateGeneraldataviewer is recovering

It can look back 7 days trends now. There is still no vacuum channels. I can bring back the channels through the restore directory, but there are no data.

  5049   Wed Jul 27 15:49:13 2011 jamieConfigurationCDSdataviewer now working on pianosa

Not exactly sure what the problem was, but I updated to the head of the SVN and rebuilt and it seems to be working fine now.

  1652   Thu Jun 4 16:54:19 2009 peteUpdateLockingdaytime DD handoff

I played with the DD handoff during the day.  The DRM dark port was flickering like a candle flame in Dracula's castle.  The demod offsets for the handoff signals looked fine.  After MICH handoff, the MICH_CTRL started to get unstable at some low frequency, maybe 3 Hz (I didn't measure).  So I increased the MICH gain from 0.1 to 0.17 and it settled down.  PRC and SRC went fine.  Then the DD_handoff script raised the MICH gain to 0.7, and an instability started to grow in MICH_CTRL (at some higher frequency).  I decreased the MICH gain from 0.7 to 0.5, and it settled down and stayed stable.

  1658   Fri Jun 5 17:22:55 2009 peteUpdateLockingdaytime locking

After fixing the tp problem, I tried locking again.  Grabbing and DD handoff, no problem.  Died earlier than last night, handing off CARM to REFL_DC, around arm power of 4 or so.  Seems to happen after turning off the moving zero, Rob says it might be touchy in daytime.

  2092   Wed Oct 14 16:59:37 2009 robUpdateLockingdaytime locking

The IFO can now be locked during the daytime.  Well, it's locked now.

  2093   Wed Oct 14 23:02:41 2009 ranaUpdateLockingdaytime locking

This is huge.    Five hours of lock only interrupted by intentional break from transfer function abuse.

  4606   Tue May 3 05:32:04 2011 kiwamuUpdateLSCdaytime tasks

Daytime tasks :

 - PRM & BS oplev (Steve)

 - LSC binary outputs (Joe/Jamie)

 - installation of the REFL55 RFPD (Suresh/Jamie)

 - Adjustment of demodulation phases (Kiwamu)

 - Bounce-Roll filters on BS and PRM (Suresh/Joe)

 - Suspension diagnostic using the free-swinging spectra (Leo)

 - PMC alignment (Jenne/Koji)

  4607   Tue May 3 10:21:25 2011 KojiUpdateLSCdaytime tasks

I think the installation of the PD DC signals are quite important. What to do
1) Connect the DC signals to the right top whitening board (be aware that there may be the modification of the whitening circuit).
2) Reconfigure the LSC model such that the DC signal is passed to the right channels (modify the left top part of the model)

Quote:

Daytime tasks :

 - PRM & BS oplev (Steve)

 - LSC binary outputs (Joe/Jamie)

 - installation of the REFL55 RFPD (Suresh/Jamie)

 - Adjustment of demodulation phases (Kiwamu)

 - Bounce-Roll filters on BS and PRM (Suresh/Joe)

 - Suspension diagnostic using the free-swinging spectra (Leo)

 - PMC alignment (Jenne/Koji)

 

  4610   Tue May 3 11:49:03 2011 KojiUpdateLSCdaytime tasks

Done. C1:PSL-PMC_PMCTRANSPD was improved from ~0.75 to 0.87.

Quote:

- PMC alignment (Jenne/Koji)

 

  6412   Wed Mar 14 05:26:39 2012 interferomter tack forceUpdateGeneraldaytime tasks

The following tasks need to be done in the daytime tomorrow.

  • Hook up the DC output of the Y green BBPD on the PSL table to an ADC channel (Jamie / Steve)
  • Install fancy suspension matrices on PRM and ITMX [#6365] (Jenne)
  • Check if the REFL165 RFPD is healthy or not (Suresh / Koji)
    • According to a simulation the REFL165 demod signal should show similar amount of the signal to that of REFL33.
    • But right now it is showing super tiny signals [#6403]
  6416   Wed Mar 14 14:09:01 2012 interferomter tack forceUpdateGeneraldaytime tasks

Quote:

The following tasks need to be done in the daytime tomorrow.

  • Hook up the DC output of the Y green BBPD on the PSL table to an ADC channel (Jamie / Steve)
  • Install fancy suspension matrices on PRM and ITMX [#6365] (Jenne)
  • Check if the REFL165 RFPD is healthy or not (Suresh / Koji)
    • According to a simulation the REFL165 demod signal should show similar amount of the signal to that of REFL33.
    • But right now it is showing super tiny signals [#6403]

 For ITMX, I used the values from the conlog:

2011/08/12,20:10:12 utc 'C1:SUS[-_]ITMX[-_]INMATRIX'
These are the latest values in the conlog that aren't the basic matricies.  Even though we did a round of diagonalization in Sept, and the 
matricies are saved in a .mat file, it doesn't look like we used the ITMX matrix from that time.

For PRM, I used the matricies that were saved in InputMatricies_16Sept2011.mat, in the peakFit folder, since I couldn't find anything in the Conlog other than the basic matricies.

 

UPDATE:  I didn't actually count the number of oscillations until the optics were damped, so I don't have an actual number for the Q, but I feel good about the damping, after having kicked POS of both ITMX and PRM and watching the sensors.

  4142   Wed Jan 12 02:41:19 2011 kiwamuUpdateGeneraldaytime tasks for tomorrow

[Rana, Kiwamu]

Here is the list for the daytime tasks of tomorrow, Jan. 12th.

The daytime task is a work basically to be done or quitted before the sun goes down.

Along with the tasks, we roughly assigned the people who are responsible for it.

The tasks below are basically separated from each other, so we can work in parallel.

 

 

--- 1.  LSC analog interface check (Joe/Koji)

   * check whitening filter

   * demodulation board check

    * check ADC connections

 

--- 2.  MC2 coil Dewhitening (Joe)

    * fix binary outputs.

    * FM9 must be the trigger of the binary outputs instead of FM10.

 

--- 3. 11MHz modulation depth (Kiwamu)

   * investigate why the depth is so low

 

--- 4. PEM DAQ name issue (Jenne)

   * change the name of seismic channels properly so that we can deal with the calibrated stuff

 

--- 5. phase adjustment for MC-PDH locking (Suresh)

 

--- 6. medm screens for C1LSC ()

    * make screens

 

 

 

  14492   Thu Mar 21 18:09:36 2019 KojiUpdateCDSdb file preparation for acromag c1susaux

I have updated the google doc spreadsheet to indicate the required action for the new dbfile generation.

There are three types of actions:

1. COPY - Just duplicate the old EPICS db entry. This is for soft channels, calc channels.
2. DELETE - Delete the entry for some physical channels that will not be implemented on Acromag (oplev, dewhitening mon, AI monitor, etc)
3. REPLACE - For the physical channels, we want to replace the port names.

The blue part of the spreadsheet indicates the action for each channel. If it is a physical channel, the assigned module and the channel are indicated there. What we still want to do is to use the these information for generating the port name which looks like "@asynMask(C1VAC_XT1221A_ADC 1 -16)MODBUS_DATA".

The links to the spreadsheets can be found on 40m wiki: https://wiki-40m.ligo.caltech.edu/CDS/SlowControls/c1susaux

  14462   Fri Feb 15 21:15:42 2019 gautamUpdateVACdd backup of c1vac made
  1. Connected one of the solid-state drives to c1vac. It was /dev/sdb.
  2. Formatted the drive using sudo mkfs -t ext4 /dev/sdb
  3.  Mounted it as /mnt/backup using sudo mount /dev/sdb /mnt/backup
  4. Started a tmux session for the dd, called DDbackup
  5. Started the dd backup using  sudo dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync
  6. Backup completed in 719 seconds: need to test if it works...
controls@c1vac:~$ sudo dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync
[sudo] password for controls: 
^C283422+0 records in
283422+0 records out
18574344192 bytes (19 GB) copied, 719.699 s, 25.8 MB/s
Quote:
 
  • Generate a bootable backup hard drive for c1vac, which could be swapped in on a short time scale after a failure.
  9937   Fri May 9 11:23:11 2014 steveUpdateGreen Lockingdecreased X green light power

Green light power decreased from 3 mW to 1 mW at the ETMX-ISCT shutter. More later.

  6300   Tue Feb 21 16:10:29 2012 kiwamuUpdateIOOdegradation in input PZT1

PZT1, the one with Koji's custom mid-HV driver (#5447), is getting degraded.

The movable range in the pitch direction became narrower than what it used to be (maybe a factor of 3 estimated by looking at the beam spots).

I think we should raise the priority level of the active TTs for the next vent.

 

I have been having a feeling that the PZT1 response is getting smaller since the end of the last year, but now I am confident

because I could see the difference between the movable ranges of Yaw and Pitch, and they used to have approximately the same amount of the movable ranges.

Right now this is not a serious issue as the beam pointing determined by the MC alignment is so good that the Pitch range doesn't rail.

I won't be surprised if it becomes completely immovable in 3 month.

  5268   Fri Aug 19 09:14:56 2011 steveUpdateIOOdegrading laser power at atm

Light into the MC is 20 mW at atm, MC_Transmitted ~10 MW = 400 count

The PMC_T is OK but something else is drifting.

  6120   Wed Dec 14 14:40:53 2011 steveUpdateGreen Lockingdelay line bnc cable specs

The existingly used used Pasternack Enterprices RG58 C/U cable lenght ~ 140 ft and the specs are here at Atm1

 

Atm2 The performance grade RG58-P coaxial cable specs.

  15174   Wed Jan 29 12:29:33 2020 shrutiUpdateGeneraldelay line frequency discriminator for PM

 Today I began working on a TF measurement based on the delay line frequency discriminator setup in elog 4254 using a single mixer (without the 'I' and 'Q' readout).

For this, I re-organised the setup for the PLL measurement of the transfer function (elog 15148), increasing the HEPA for the initial changes while the PSL door was open, and then reverting it back to ~30%:

  • I removed the 20dB coupler and connected the splitter directly after the amplifer to split the beat note signal into two coaxial cables one of which was ~1.5m longer than the other
  • The recombined signals were combined in a mixer outside the PSL enclosure. I also replaced the 1.9 MHz LPF with a 5 MHz LPF.
  • I used an SR 560 to amplify the signal after the LPF.

With the above setup the power that was seen at each channel of the delay line was <1dBm, which is not ideal for the any of the available mixers.

After the group meeting, I changed the amplifer to ZHL-3A (that is near the beat mouth) instead of a ZFL-500HLN because it had a higher gain (~28dB as opposed to ~19dB of the latter). The power seen at each of the delay line channels is over 5.5 dBm. This is consistent with the estimation 0 dBm beat -> -20 dBm after 20dB coupler -> 8 dBm after amplifier -> 5 dBm after splitter with insertion loss of 3 dB.

Is this sufficient enough for the mixer to work? In Attachment 1: A shows the mixer output (point B in Attachment 2) when the IMC is locked, in B the IMC is unlocked at the middle of the spectrum, and each of the dips show the DC voltage being sent to the PSL temperature servo being decreased by 0.01 V.

Gautam pointed me to the location of a few other RF amplifiers (ZHL-32A+, ZHL-1A) which don't possess a higher gain but can be used without disrupting the ALS related work (I was told).

For shorter duration changes that I made later, I opened and closed the PSL enclosure doors without changing the HEPA.

Attachment 2 shows the current setup as is, but I might add a PSL servo tomorrow to stabilise its frequency corresponding to a null mixer output without driving anything else.

  15177   Thu Jan 30 15:24:10 2020 ?UpdateGeneraldelay line frequency discriminator for PM

yes, its fine to use this with a level 3 or level 7 mixer; let's see some PM transfer functions !

Quote:

Is this sufficient enough for the mixer to work?

  15180   Thu Jan 30 22:02:42 2020 shrutiUpdateGeneraldelay line frequency discriminator for PM

I could not find any level 3 mixers, but by adjusting the beat frequency the power in each of the delay line channels rose to almost 6.5 dBm.

In short: Delay line seems to work

Things I did earlier today:

  1. Played with the slow servo on the FSS screen, but then reset the parameters to what was there before (Later found out that this was to lock the PSL freq to the IMC when the IMC power is significant.)
  2. Connected the AG 4395A to the X PZT
  3. Closed the PSL shutter

Transfer function measurement: (Refer Attachment 1)

Everything about the setup remained as I had left it earlier: described in elog 15174

except

  • SR560 gain set to 10, DC coupled
  • DC block at channel A of Agilent (The measurement was A/R)

I did not use a slow servo, but took individual sweeps adjusting the PSL temperature each time to bring the error voltage between +/-25 mV. The beat frequency was over 100 MHz.

For the plot posted in Attachment 1, the measurement paramters are the following. Will do further measurements/analysis tomorrow.

# AG4395A Measurement - Timestamp: Jan 30 2020 - 21:58:00
# Parameter File: TFAG4395Atemplate.yml
#---------- Measurement Parameters ------------
# Start Frequency (Hz): 50000.0, 50000.0
# Stop Frequency (Hz): 1000000.0, 1000000.0
# Frequency Points: 801, 801
# Measurement Format: LOGM, PHAS
# Measuremed Input: AR, AR
#---------- Analyzer Settings ----------
# Number of Averages: 1
# Auto Bandwidth: Off, Off
# IF Bandwidth: 1000.0, 1000.0
# Input Attenuators (R,A,B): 0dB 0dB 0dB 
# Excitation amplitude = -20.0dBm

Quote:

yes, its fine to use this with a level 3 or level 7 mixer; let's see some PM transfer functions !

Quote:

Is this sufficient enough for the mixer to work?

  6199   Sun Jan 15 10:28:02 2012 DenUpdateAdaptive Filteringdelays

We can account for delays in the oaf system by compensating it in the adaptive path of the filter. But using only this procedure is not enough. Parameters mu and tau should be chosen accurately:

w = (1 - tau) * w;

w += mu * dw / norm;

NLMS algorithm without considering delays works well for mode cleaner length and gur1 seismometer signals, significantly reducing MC_F  with parameters mu=1, tau=0. These parameters are considered because nlms algorithm should converge with the highest speed when mu=1. However, if the system has a delay so at time moment n:

error_signal [n] = desired_signal [n] - filter_output [n-delay];

then the adaptive filter diverges for the same parameters mu=1 and tau=0 even for delay=1. For that reason we make the same calculations with tau = 1e-4 and tau = 1e-2 without reducing mu conserving the adaptation rate and get the same result as nlms algorithm without delays. Next figure shows MC_F signal, error after applying e-nlms filter with tau=1e-4 and tau=1e-2. "e-" is added to show that  a small number (epsilon) is added to the norm of the signal in order to prevent the filter from diverging in the beginning of the process when the norm is not well-determined yet.

2048_tau.png

The test was done offline with the sampling frequency 2048 Hz, without downsampling and any filters. We can see that tau=1e-4 is still not enough, tau=1e-3 or tau=1e-2 is as good as nlms without delays, tau=1e-1 and high are also bad.

Correctly choosing tau we have some freedom for delay compensation in the adaptation path. This is important as we do not know exactly what is the delay in the real system. We can measure it approximately. In order to figure out the range of reasonable delay errors we make a test with delay = 1, but to the adaptation path we give delays from 0 to 10. It turns out that adaptation path delays greater then 5 make the filter diverge, delays in the range 0-3 produce a reasonable error. In the figure below errors with adaptation path delays = 1 (correct) and 3 are presented.

2048_delays.png

  4554   Thu Apr 21 21:24:41 2011 kiwamuUpdateLSCdemod board : new 90 deg splitter

A new 90 degree splitter, PSCQ-2-51W, has arrived today and I installed it on a demod board called AS11.

Results of the I-Q phase measurement with the new splitter will be reported soon.

 

 * Picture 1 = before removal of the handmade coil

 * Picture 2 = after removal of the coil and the associated capacitors

 * Picture 3 = after soldering PSCQ-2-51-W

DSC_2949_ss.jpg

DSC_2951.JPG

DSC_2952_ss.jpg

Quote from #4358

 First of all we will replace the home-made 90 degree splitter (see this entry) by a commercial splitter, PSCQ-2-51-W+ from Mini circuit. This is the step 1 basically.

  4555   Thu Apr 21 21:46:22 2011 kiwamuUpdateLSCdemod board : new 90 deg splitter

A less LO power dependence on the relative phase was found. The new 90 deg splitter works better.

From -3 dBm to 10 dBm in LO power, the relative phase is within 90 +/- 5 deg.

As a comparison I plot the phase that I measured when the handmade coil had been there (green curve in the plot).

relativephase.png

 

 I will also measure amplitude unbalances between I and Q.

Quote from #4554

A 90 degree splitter, PSCQ-2-51W, has arrived today and I installed it on a demod board called AS11.

Results of the I-Q phase measurement with the new splitter will be reported soon.

 

 

  4560   Fri Apr 22 11:08:50 2011 kiwamuUpdateLSCdemod board AS11 : amplitude imbalance

Amplitude imbalance between I and Q in a demod board, AS11, with the new 90 deg splitter was measured.

It shows roughly 10% amplitude imbalance when the LO power is in a range from 0 to 5 dBm. Not so bad.

 

  With the handmade coil there used to be a huge imbalance (either I or Q goes to zero volt while the other keeps about 1 V rms) as the LO power decreases.

But with the new 90 deg splitter now there are no more such a huge imbalance.

The remaining 10 % imbalance possibly comes from the fact that we are using ERA-5 in each I and Q path. They may have such gain imbalance of 10%.

We should check the ERA-5 gains so that we can confidently say ERA-5 causes the amplitude imbalance.

Then our plan replacing the ERA-5s (see here) will sound more reasonable.

IQamplitude.png

 

Quote from #4555

The new 90 deg splitter works better.

 I will also measure amplitude unbalances between I and Q.

 

  4538   Mon Apr 18 13:05:57 2011 kiwamuSummaryLSCdemod board modification

Here is the idea how we upgrade the demodulation boards.

Basically we go ahead with two steps as depicted in the cartoon diagram below.

Once we finish the first step of upgrade, the board will be ready to install although the circuit won't be awesome in terms of noise performance.

 

demod_board.png

 

* * * (details) * * *

 First of all we will replace the home-made 90 degree splitter (see this entry) by a commercial splitter, PSCQ-2-51-W+ from Mini circuit. This is the step 1 basically.

At this point the boards will be ready to use in principle. I asked Steve to get three 90 degree splitters so that we can have at least three demodulators for the dual-recycled Michelson locking.

If they work very fine we will buy some more 90 degree splitters for full locking.

While we try to lock the dual-recycled Michelson once we will get a Cougar amplifier, remove all ERA-5s and install it such that we don't have to gain up and down in the circuit. This is the last step.

  277   Sun Jan 27 13:13:21 2008 tobinMetaphysicsGeneraldeparture
It's been grand. Thanks for having me!

GWAVES IN '08!

Sugar napoleons may be forwarded to T. F., c/o LLO, P.O. Box 940, Livingston, LA 70754-0940.
  2525   Tue Jan 19 02:39:57 2010 kiwamuUpdateElectronicsdesign complete --- triple resonant circuit for EOM ---

The design of the triple resonant circuit has been fixed.

I found the optimum configuration, whose gain is still 11 at 55MHz even if there are realistic losses.

As I mentioned in the last entry, there are infinite number of the similar solutions to create the same resonant frequencies.

However owing to the effect of the losses, the resultant gain varies if the similar solution changes

The aim of this study is to select the optimum solution which has a maximum gain ( = the highest impedance at the resonance ).

In order to handle the losses in the calculation, I modeled the loss for both inductors and the capacitors.

Then I put them into the circuit, and calculated the impedance while changing the solutions.

 


 

(method)

1). put the scaling parameter as k in order to create the similar solution.

2). scale the all electrical parameters (L1, L2,...) by using k, so that C1'=C1 x k, L1'=L1/k ,...

3). Insert the losses into all the electrical components

4). Draw the impedance curve in frequency domain.

5). See how the height of the impedance at the resonance change

6). Repeat many time this procedure with another k.

7). Find and select the optimum k

scaling.png

There is a trick in the calculation.

I put a capacitor named Cpp in parallel to the EOM in order to scale the capacitance of the EOM (see the schematic).

For example if we choose k=2, this means all the capacitor has to be 2-times larger.

For the EOM, we have to put Cpp with the same capacitance as Cp (EOM). As a result these two capacitors can be dealt together as 2 x Cp.

So that Cpp should be Cpp = (k-1) Cp, and Cpp vanishes when we choose k=1.

 

The important point is that the scaling parameter k must be greater than unity, that is k > 1.

This restriction directly comes from Cp, the capacitance of the EOM, because we can not go to less than Cp.

If you want to put k < 1, it means you have to reduce the capacitance of the EOM somehow (like cutting the EO crystal ??)

 

(loss model)

I've modeled the loss for both the inductors and the capacitors in order to calculate the realistic impedance.

The model is based on the past measurements I've performed and the data sheet.

   Loss for Capacitor :  R(C) = 0.5 (C / 10pF)^{-0.3} Ohm

   Loss for Inductor :    R(L) = 0.1 ( L / 1uH) Ohm

Of course this seems to be dirty and rough treatment.

But I think it's enough to express the tendency that the loss  increase / decrease monotonically as  L / C get increased.

These losses are inserted in series to every electrical components.

( Note that: this model depends on both the company and the product model. Here I assume use of Coilcraft inductors and mica capacitors scattered around 40m )

 

( results )

The optimum configuration is found when k=1, there is no scaling. This is the same configuration listed in last entry

Therefore we don't need to insert the parallel capacitor Cpp in order to achieve the optimum gain.

The figure below shows the some examples of the calculated impedance. You can see the peak height decrease by increasing the scale factor k.

realistic.png

The black dash line represents the EOM-loss limit, which only contains the loss of the EOM.

The impedance at the resonance of 55MHz is 6.2 kOhm, which decreased by 3% from the EOM-loss limit. This corresponds to gain of G = 11.

The other two peaks, 11MHz and 29.5MHz dramatically get decreased from EOM-loss limit.

I guess this is because the structure below 50MHz is mainly composed by L1, L2, C1, C2.

In fact these components have big inductance and small capacitance, so that it makes lossy.

 

( next step )

The next step is to choose the appropriate transformer and to solder the circuit.

  2528   Tue Jan 19 03:20:28 2010 KojiUpdateElectronicsdesign complete --- triple resonant circuit for EOM ---

First I was confused, but now I think I understood.

My confusion:
If the k get bigger, L get smaller, C get bigger. This makes R(L) smaller and R(C) smaller. This sounds very nice. But why smaller k is preferable in the Kiwamu's result?

Explanation:
The resultant impedance of the network at a resonance is determined by Zres = L/(R C) or something like that. Here R = R(L)+R(C). (I hope this is right.)

Here larger Zres is preferable. So smaller R is nice.

But If the speed of reduction for R is slower than that of L/C (which is proportional to k^-2), increasing k does not help us to increase of Zres. And that's the case.

This means "if we can put the LC network in the box of EOM, we can do better job!" as we can reduce Cp.

Quote:

scaling.png


   Loss for Capacitor :  R(C) = 0.5 (C / 10pF)^{-0.3} Ohm

   Loss for Inductor :    R(L) = 0.1 ( L / 1uH) Ohm

  6817   Thu Jun 14 04:53:39 2012 yutaSummaryGreen Lockingdesigning ALS loop for mode scan

[[Requirement]]
 Arm cavity FWHM for IR is

  FWHM = FSR / F = c/(2LF) = 8 kHz.

 In cavity length, this is

  L/f * FWHM = 40m/(c/1064nm) = 1.2 nm

 So, to do mode scan nicely, arm length fluctuation during resonant peak crossing should be much less than 1.2 nm.


[[Diagram]]
 Let's consider only ADC noise and seismic noise.
ALSloop.png

* S: conversion from Y arm length to the beat frequency

  dL/L = df/f

 So,

  S = df/dL = f/L = c/532nm/40m = 1.4e7 MHz/m


* W: whitening filter

 We set it to flat gain 50. So,

  W = 50


* D: AD conversion of voltage to counts

 D = 2^16counts/20V = 3300 counts/V


* B: frequency to voltage conversion of the beatbox.

 We measured BWD(elog #6815). When we measured this, W was 10. So, the calibration factor at 0 crossing point(~ 50 MHz) is

  B = 1400*0.048/10/D = 0.0021 V/MHz


* A: actuator transferfunction

 I didn't measure this, but this should look like a simple pendulum with ~ 1 Hz resonant frequency.


* n_ADC: ADC noise

 ADC noise is about

  n_ADC = sqrt(2*LSB^2*Ts) = sqrt(2*(20V/2^14)**2*1/64KHz) = 1.6 uV/rtHz


* n_seis: seismic noise

 We measured this by measuring C1:ALS-BEATY_COARSE_I_IN1. This is actually measuring

  D(WBSn_seis + n_ADC)

 Calibrated plot is the red spectrum below.


* F: servo filter (basically C1:ALS-YARM)

 We need to design this. Stabilized arm length fluctuation is

  x_stab = 1/(1+G)*n_seis + G/(1+G)*n_ADC/(WBS)

 where openloop transferfunction G = SBWDFA.
 Below ~ 50 Hz, n_seis is bigger than n_ADC/(WBS). We don't want to introduce ADC noise to the arm. So, UGF should be around 50 Hz. So, we need phase margin around 50 Hz.
 We also need about 10^3 DC gain to get the first term comparable to the second term.

 Considering these things, openloop transferfunction should look like the below left. Expected error signal when ALS on is the below right. I put some resonant gain to get rid of the peaks which contribute to the RMS (stack at 3.2Hz, bounce at 16.5 Hz).
 Inloop RMS we get is about 0.3 nm, which is only 4 times smaller than FWHM.
ALSopenloop.pngyarmlength.png



[[Discussion]]
 We need to reduce RMS more by factor of ~ 30 to get resolusion 1% of FWHM.
 Most contributing factor to the RMS is power line noise. We might want comb filters, but it's difficult because UGF is at around this region.

 So, I think we need more fancy whitening filters. Currently, we can't increase the gain of the whitening filter because SR560 is almost over loading. Whitening filter with zero at 1 Hz might help.

  3647   Tue Oct 5 11:42:20 2010 kiwamuSummaryGreen Lockingdeveloping green locking plant

 With a help from Joe, I made a diagram of the simulated plant for green locking in order to get better understanding and consensus.

Eventually these simulated plants will help us developing (sometimes debugging) the digital control systems.

Here is the diagram which tells us how we will setup and link the control/plant models and on which machine they will be running.

green_sm3.png

 

Basically upper side represents the realtime control, and the lower side is the simulated plant.

The models are talking to each other via either a local shared memory (orange line) or the reflective memory network (purple line).

 Each model is stil not systematically named, at some point we have to have an absolute standard for naming the models.

 

- current model names -

  GCV = Green Control model at Vertex

  GCX(Y) = Green Control model at X (Y) end

  GPV = Green Plant model at Vertex

 

 - things to be done -

1. let the RFM work

2. revise the old plant models : SUP, SPX(Y) and LSP

 

  13290   Mon Sep 4 18:18:29 2017 ranaUpdateLSCdewhite switching: FOTON settings

not immediately necessary, since you have already got it sort of working, but one of these days we should optimize this for real. In the past, we used to do this by putting a o'scope on the coil Vmon during the switching to catch the transient w/ triggering. We download the data/picture via ethernet. Run for loop on tolerance to see what's what.

  1. Went into the Foton filter banks for all the coil output filters, and modified the "Output" settings to be on "Input crossing", with a "Tolerance" of 10 and a "Timeout" of 3 seconds. These settings are to facilitate smooth transition between the two signal paths (without and with coil-dewhitening). The parameters chosen were arbitrary and not optimized in any systematic manner.

 

  5765   Sun Oct 30 23:01:51 2011 ZachUpdateSUSdiagAllSUS -- automated input matrix generator

I finally got around to wrapping up the SUS input matrix diagonalizer. The files I have added to ...scripts/SUS/peakFit are:

  • kickAll: Restores all SUS angle biases using /cvs/cds/rtcds/caltech/c1/medm/c1ifo/cmd/C1IFO_OPTICrestore.cmd XXXX &, then runs 'freeswing all'. Finally, writes an elog entry with the time when the optics were kicked and saves the gps time to 'kickAll.time'.
  • diagAllSUS.m: An M-file that calls all the other individual M-files needed for the matrix generation. What it does:
    • Reads kick time from kickAll.time
    • Runs getSensors.m to get time series from all optics' sensors
    • Runs makeSUSSpectra.m to generate spectra from time series
    • Runs findPeaks.m to fit spectra for peak frequencies
    • Loops through all optics and runs, in sequence:
      • inmat = findMatrix(XXXX) to generate the matrix for each optic
      • writeSUSinmat(XXXX,inmat) to write that matrix to the frontend
  • diagAllSUS: A wrapper for diagAllSUS.m. It also writes an elog entry and attaches the pre and post spectra demonstrating the diagonalization. The entry following this one is an example.

The following lines should eventually be added to the controls@nodus crontab:

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/kickAll

0 18 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/diagAllSUS

(i.e., do the kick at 8am on Sundays and run the diagonalization 10 hrs later at 6pm). They can be done on a different machine but then my elog commands will need to be modified.

Before we add them, we should check that they do, in fact, work. We can do this sometime while I'm at the 40m this week.
 

  3844   Tue Nov 2 11:34:53 2010 josephb, alexUpdateCDSdiagconfd running, excitations back in dtt

Problem:

Diagnostic test tools was starting with errors.

Cause:

After the reboot of the frame builder machine yesterday by Alex, the diagconfd daemon was not getting started by xinetd.  There was a sequence error in the startup where xinetd was being called before mounting drives from linux1.

Important Note:

If you do not see the "nds" line you would not have diagnostic tests enabled in the DTT:

[controls@rosalba apps]$ diag -i | grep nds
nds * * 192.168.113.202 8088 * 192.168.113.202

Solution:

Alex changed /etc/xinetd.d/diagconfd file to point to /opt/apps/gds/bin/diagconfd instead of /opt/apps/bin/diagconf.  He also ensured xinetd started after mounting from linux1.

Alex's Suggestion:
My feeling is we should get rid of this feature and have an NDS address
entry box in the "Online" tab in the DTT with the default "nds". I
mentioned this to Jim Batch and he greed with me, so maybe he is going to
implement this. So maybe you guys want to request the same thing too, send
the request to Rolf and Jim, so we can have the last demon exercised.

  2146   Mon Oct 26 19:12:50 2009 kiwamuUpdateLSCdiagnostic script for LSC timing

The diagnostic script I've written is available in the 'caltech/users/kiwamu/work/20091026_OMC-LSC-diag/src'.

To run the script, you can just execute 'run_OMC_LSC.sh' or just call the m-file ' OMC_LSC_timinig.m'  from matlab.

 

NOTES:

The script destructs the lock of DARM and OMC, be careful if you are working with IFO.

ELOG V3.1.3-