40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 2 of 346  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Type Category Subject
  17390   Tue Jan 10 16:06:58 2023 yutaSummaryPSLPMC transmission dropped to 0.68

[JC, Paco, Yuta]

It seems like PMC transmission (C1:PSL-PMC_PMCTRANSPD) dropped to ~0.68 from ~0.74 on Dec 27.
We tried to tweak PZT offset for PMC loop and input alignment to PMC, but PMC transmission didn't increased.
PSL laser temperature was also sweeped in the range 30.3 - 31.6 degC, but didn't help. The PSL temperature was reverted to original 30.61(1) degC.
Power measured at PSL output now is 893 mW (measured at our standard place shown in 40m/16672), which used to be 951 mW in June 2022 (40m/16886).
Power measured at PMC input (see attached photo) now is 1.18 W.

 - What was the previous PMC input power we had?
 - Sweep PSL laser temperature for larger range

Attachment 1: Screenshot_2023-01-10_14-26-46.png
Attachment 2: IMG_1994.JPG
  17389   Tue Jan 10 15:07:33 2023 JCUpdateGeneralClean Large Optical Table

I have been working on cleaning the large optical table next to the PSL table. I have placed the known optics along in the optical cabinets Section Y5. Post and pillars have been placed in a cabinet along X-Arm. (I will work on gathering optics and optical hardware into a single area in the future, having them separated is only temporary.) I found some optics that were chipped and/or unlabeled. These have been placed in a box. 

There were cables coming into this table from the wire rack above, I plan on removing this. If there are any issues with me doing this, please message me. 

My main purpose for cleaning this is to potentially have an open area to place OMC for the next vent. We can also move the PD Testing table here. 

Attachment 1: IMG_6465.JPG
  17388   Mon Jan 9 19:41:01 2023 AnchalUpdateSUSNull stream (butterfly/pringle) row added and DQed

I updated the suspension model (/cvs/cds/rtcds/userapps/trunk/sus/c1/models/lib/sus_single_control_new.dml) to add a 5th row in the input matrix so that we can put in the calculated NULL stream vector (also have been called as Butterfly mode or Pringle mode in the past). The output of this row would go through a filter module and then is sent to the testpoint named 'C1:SUS-OPT_SENSOR_NULL' where OPT is the optic acronym. This channel is acquired in frames at 256 Hz and would be available as C1:SUS-OPT_SENSOR_NULL_DQ. After the update in the model, I built, installed and restarted models c1sus, c1mcs, c1scx, c1scy, c1su2, and c1su3. Then I restarted daqd, and everything came up nicely. After but restore, I added the null stream vector for the optics it was already known from a free swing test. ITMX, ITMY, ETMX, PRM, and SRM null stream vectors needs to be calculated from the other 4 rows. It is set to zero right now. Medm screen for the input matrix was also updated to allow seeing this row.


Attachment 1: SUS_Model_Changes.png
Attachment 2: MC1_INMATRIX.png
  17387   Thu Jan 5 14:30:32 2023 PacoHowToDAQnds2 server restart

After being unable to fetch data offsite using the nds40 server, I found enlightment here. Our nds2 server is running on megatron and the link before should be sufficient to restore it after any hiccups. yes

  17386   Wed Jan 4 17:15:41 2023 KojiConfigurationCDSunknown dhcp request to fb1

The dhcpd error on the log file stopped when the yellow (DAQ) ethernet cable was removed. With Chris's permission I left it unconnected (Attachment 1).

Chris pinted that the IPMI on c1shimmer is supposed to be exposed to 192.168.113. net rather than DAQ net.

From dhcpd.conf on chiara:

host c1shimmer-ipmi {
  hardware ethernet 3c:ec:ef:c8:44:78;

So the ethernet connections of c1shimmer is still questionable. The next person to work with c1shimmer needs to check them.


This would also be related?

Attachment 1: PXL_20230104_233926284.MP.jpg
  17385   Wed Jan 4 15:10:19 2023 KojiConfigurationCDSunknown dhcp request to fb1

Jamie reported that:

The logs (/var/log/daemon.log) on fb1 are filling with this line:

Jan 03 14:11:51 fb1 dhcpd[1152]: DHCPDISCOVER from 3c:ec:ef:c8:44:78 via enp3s0: network no free leases

It seems that some machine on the network is trying to get an IP address but can't

  • The MAC address 3c:ec:ef:xx:xx:xx indicates this is one of the supermicro units.
  • The IP address indicates this is on the DAQ network which fb1 is spanning.
  • There is a switch for this DAQ network. 
  • There are 8 machines connected to the switch. fb1 is via optical, and the other 7 have yellow ethernet cables (Attachment 1).
  • fb1 and other 6 RT machines already have 10.0.113.x assigned.
  • The rest is c1shimmer. I can't ssh into it from martian. KVM on rack 1X7 shows a black screen assuming 1-7 is c1shimmer. I wonder what's the status of this machine, but left untouched so far.
Attachment 1: PXL_20230104_233907953.jpg
  17384   Wed Jan 4 12:12:57 2023 PacoSummaryCalibrationALS calibration error from DFD

[Paco, Anchal]

One of the crucial and currently limiting calibration errors is in the ALS beat. We think a major driver of calibration uncertainty may be the DFD TF calibration since it depends on the RF beat power.

The RF beat power as monitored by C1:ALS-BEATY_RF_POW shows relative fluctuations of 0.02% at the 16 Hz sampling rate (actually 0.09% rms from Attachment #1) once the single arm and YAUX laser are both locked. This sounds ok, but that's just a statistical estimate. The beat frequency changes every time we break and reacquire the lock, making the BEAT PD frequency response and DFD overall calibration change their nominal TF. This changes can be significantly larger than 0.02% (e.g 4.9% = observed change in the RF power after breaking and reacquiring the YAUX lock this morning). This is far more significant than the contribution from the RIN on the two lasers.

This kind of systematic error could be addressed by either/all:

  • Stabilizing the ALS BEAT absolute frequency (offset locking using freq counter and simple integrator or equivalent)
  • Rejecting RF beat amplitude fluctuations by mixing a stable DC voltage in the DFD, or using a comparator. 
    • Our plan this afternoon is to quickly measure the RF AM rejection level from a simple mixer and a stable voltage reference and plan ahead.
  • ISS on both lasers
Attachment 1: als_rf_power_screenshot.png
  17383   Wed Jan 4 08:52:11 2023 JCUpdateOPLEV TablesETMX laser has died

Koji mentioned to me that this laser has a degraded output. I removed this replacement laser and put in a new laser from the Y Arm Cabinets, Attachment #1. I placed the degraded laser back to its visitor setup and tested with the power supply, this is shown in Attachment #2. Along with this, I also labeled this laser as degraded.

Attachment 1: DACBE2CD-35EB-4314-92FD-71C5270A6961.jpeg
Attachment 2: 45D7AF8F-5955-4036-B8AE-D761C2838408.jpeg
  17382   Tue Jan 3 17:41:55 2023 KojiUpdateCDSChiara local backup

Chris modified the fstab so that the disk is automatically mounted. The key was that these two disks have an identical UUID and use this UUIS for mounting. I confirmed that /cvs/cds was properly backup-ed on Jan 4th.

controls@chiara:~$ lsblk
sda       8:0    0  1.8T  0 disk
├─sda1    8:1    0  512M  0 part  /boot/efi
├─sda2    8:2    0  1.8T  0 part  /
└─sda3    8:3    0 31.9G  0 part  [SWAP]
sdb       8:16   0  5.5T  0 disk
└─sdb1    8:17   0  5.5T  0 part  /home/cds
sdc       8:32   0  5.5T  0 disk
└─sdc1    8:33   0  5.5T  0 part
  └─md0   9:0    0  5.5T  0 raid1 /media/40mBackup
sdd       8:48   0  5.5T  0 disk
└─sdd1    8:49   0  5.5T  0 part
  └─md0   9:0    0  5.5T  0 raid1 /media/40mBackup

controls@chiara:~$ sudo blkid
/dev/sdc1: UUID="052f9129-f2eb-6ef1-473d-a748a1ffa5d3" UUID_SUB="9ac96976-e1d5-cc01-13f7-10944d5d6735" LABEL="chiara:0" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="5cf6aac7-3f29-42e0-8db6-de2978ca84f0"
/dev/sdd1: UUID="052f9129-f2eb-6ef1-473d-a748a1ffa5d3" UUID_SUB="9f124649-ff79-e406-54ab-6374b4acddf1" LABEL="chiara:0" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="01296513-46cf-4210-8d59-6f6bc25934ee"

/dev/sda1: UUID="69C0-DD2F" TYPE="vfat" PARTUUID="00ac6b04-2675-4842-9193-ee5c4575b4b4"
/dev/sda2: UUID="75f19654-1504-4548-b9a7-95f22d507cb4" TYPE="ext4" PARTUUID="f5022aff-7f84-4e72-9dfa-44b0412e907b"
/dev/sda3: UUID="e9d6a5b7-78e7-4373-9bac-0509458860cd" TYPE="swap" PARTUUID="f7388c20-b17e-4f21-9093-1df58d00d9e3"
/dev/sdb1: LABEL="cvs" UUID="eceb000f-9493-45fd-85f1-2c95c6819f4a" TYPE="ext4" PARTUUID="2e090790-7d03-406d-8ee9-5a5c96e14258"
/dev/md0: UUID="6d16f518-1332-42c3-ad16-0a9d384c6dad" TYPE="ext4"

controls@chiara:~$ cat /etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=75f19654-1504-4548-b9a7-95f22d507cb4 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=69C0-DD2F  /boot/efi       vfat    defaults        0       0
# swap was on /dev/sda3 during installation
UUID=e9d6a5b7-78e7-4373-9bac-0509458860cd none            swap    sw              0       0
UUID=eceb000f-9493-45fd-85f1-2c95c6819f4a    /home/cds    ext4    errors=remount-ro    0    1
UUID=6d16f518-1332-42c3-ad16-0a9d384c6dad    /media/40mBackup    ext4    errors=remount-ro    0    1

  17381   Tue Jan 3 16:11:05 2023 KojiUpdateCDSChiara local backup

I checked how the local backup of our /cvs/cds is done. The last backup was taken on 2022-12-15 and it kept failing since 2022-12-16.

controls@chiara:/opt/rtcds/caltech/c1/scripts/backup$ tail -100 localbackup.log

2022-12-15 07:00:02,404 INFO       Updating backup image of /cvs/cds
2022-12-15 07:17:51,901 INFO       Backup rsync job ran successfully, transferred 1,352 (reg: 1,288, dir: 64) files.
2022-12-16 07:00:01,650 INFO       Updating backup image of /cvs/cds
2022-12-16 07:00:01,668 ERROR      External drive not mounted!!!


The backup destination is /media/40mBackup according to /opt/rtcds/caltech/c1/scripts/backup/localbackup
During the power outage on Dec 15, 2022 (<- not well elogged), the volume was probably unmounted.
This disk is missing although some spare disks exist. The disks are indicated as RAID1. I'll ask Chris if he knows what the current configuration is and how to add it to fstab.

controls@chiara:/opt/rtcds/caltech/c1/scripts/backup$ df
Filesystem      1K-blocks       Used  Available Use% Mounted on
udev             16394928          0   16394928   0% /dev
tmpfs             3283044     123944    3159100   4% /run
/dev/sda2      1888292368   13161244 1779137424   1% /
tmpfs            16415220          0   16415220   0% /dev/shm
tmpfs                5120          0       5120   0% /run/lock
tmpfs            16415220          0   16415220   0% /sys/fs/cgroup
/dev/sda1          523248       3620     519628   1% /boot/efi
/dev/sdb1      5814157460 2604230900 2916884052  48% /home/cds
tmpfs             3283044          8    3283036   1% /run/user/1001
tmpfs             3283044          4    3283040   1% /run/user/114

controls@chiara:/opt/rtcds/caltech/c1/scripts/backup$ lsblk
sda       8:0    0  1.8T  0 disk
├─sda1    8:1    0  512M  0 part  /boot/efi
├─sda2    8:2    0  1.8T  0 part  /
└─sda3    8:3    0 31.9G  0 part  [SWAP]
sdb       8:16   0  5.5T  0 disk
└─sdb1    8:17   0  5.5T  0 part  /home/cds
sdc       8:32   0  5.5T  0 disk
└─sdc1    8:33   0  5.5T  0 part
  └─md0   9:0    0  5.5T  0 raid1
sdd       8:48   0  5.5T  0 disk
└─sdd1    8:49   0  5.5T  0 part
  └─md0   9:0    0  5.5T  0 raid1

  17380   Tue Jan 3 15:28:12 2023 JCUpdateOPLEV TablesETMX laser has died

Seems that the ETMX laser died over the break and took an extended vacation. I swapped the laser out with one Koji would use to model Suspension wires.

The laser which died out seems a bit new though, it was manufactured in Jan 2019. A photo of this laser is attached.

Attachment 1: Screen_Shot_2023-01-03_at_3.37.07_PM.png
  17379   Tue Jan 3 12:10:46 2023 JamieUpdateCDSYearly DAQD fix 2023, did not work :(

This whole procedure is no longer needed after the CDS upgrade.  We don't do things in the old hacky way anymore.  The gpstime kernel module does not need to be hacked anymore, and it *should* keep up with leap seconds properly...

That said, there was an issue that @christopher.wipf id'd properly:

  • The front end models were not getting the correct GPS time because the offset on their timing cards was off by a year.  This is because the timing cards do not get the year info from IRIG-B, so the offset they had when the models were loaded in 2022 was no longer valid as soon as the year rolled over to 2023.
  • This meant that the data sent from the front ends to the DAQ was a year old, and the DAQ receiver process (cps_recv) was silently dropping the packets because the time stamps were too off.

So to resolve the issue the /usr/share/advligorts/calc_gps_offset.py program needed to be run on the front ends, and all the models needed to be restarted (or all the front ends need to be restarted).  Once that happens the data should start flowing properly.

NOTE the DAQD no longer uses the gpstime kernel module, so the fact that the gpstime module was reporting the wrong time on fb1 did not affect anything.

Anchel restarted the front ends which fixed the issue.

We got new timing hardware from Keith at LLO which will hopefully resolve the year issue (if it's ever installed) so that we won't have to go through these shenanigans again when the year rolls over.  The sites don't have to deal with this anymore.

Issues reported upstream:

  •  better logging from the cps_recv process to report why there is no data coming through
  •  fix packaging for advligorts-daqd to not depend on the gpstime kernel module

Also note that the code in /opt/rtcds/rtscore is completely obsolete and is not used by anything and that whole directory should be purged

  17378   Tue Jan 3 11:32:32 2023 AnchalUpdateCDSYearly DAQD fix 2023, did not work :(

Every year some changes need to be done manually in a driver c code file for daqd to work. The gpstime offset needs to be changed on fb for some package.

We followed the procedure on this thread, but this year it did not work. Here is a summary of our findings:

We first confirmed this is indeed the issue by doing:

controls@fb1:~$ cat /proc/gps

This is clearly wrong gpstime. We went to the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c in fb1 and added following lines after line 110:

/* 2022 has no leap seconds or leap days, so adjust for that */
       pHardware->gpsOffset += 31536000;

After this, we went to  /opt/rtcds/rtscore/release/src/drv/symmetricom and ran:

controls@fb1:/opt/rtcds/rtscore/release/src/drv/symmetricom$ sudo make
make -C /lib/modules/4.19.0-6-rtcds-amd64/build SUBDIRS=/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.0-6-rtcds-amd64'
  CC [M]  /opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.o
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:59:27: error: initialization of ‘long int (*)(struct file *, unsigned int,  long unsigned int)’ from incompatible pointer type ‘int (*)(struct inode *, unsigned int,  long unsigned int)’ [-Werror=incompatible-pointer-types]
         .unlocked_ioctl = symmetricom_ioctl,
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:59:27: note: (near initialization for ‘symmetricom_fops.unlocked_ioctl’)
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c: In function ‘get_cur_time’:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:89:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
  int sync = getGpsTime(&timeSec, &timeUsec);
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c: In function ‘symmetricom_ioctl’:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:116:23: error: implicit declaration of function ‘copy_to_user’; did you mean ‘raw_copy_to_user’? [-Werror=implicit-function-declaration]
                   if (copy_to_user ((void *) arg, &res,  sizeof (res))) return -EFAULT;
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c: In function ‘symmetricom_init’:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:175:26: error: implicit declaration of function ‘create_proc_entry’; did you mean ‘remove_proc_entry’? [-Werror=implicit-function-declaration]
         proc_gps_entry = create_proc_entry("gps", PROC_MODE, NULL );
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:175:24: warning: assignment to ‘struct proc_dir_entry *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
         proc_gps_entry = create_proc_entry("gps", PROC_MODE, NULL );
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:181:23: error: dereferencing pointer to incomplete type ‘struct proc_dir_entry’
         proc_gps_entry->read_proc = procfile_gps_read;
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:188:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
  struct pci_dev *symdev = pci_get_device (SYMCOM_VID, SYMCOM_BC635_TID, 0);
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:222:3: warning: label ‘out_remove_proc_entry’ defined but not used [-Wunused-label]
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:158:22: warning: unused variable ‘pci_io_addr’ [-Wunused-variable]
  static unsigned int pci_io_addr;
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:156:6: warning: unused variable ‘i’ [-Wunused-variable]
  int i;
At top level:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:158:22: warning: ‘pci_io_addr’ defined but not used [-Wunused-variable]
  static unsigned int pci_io_addr;
cc1: some warnings being treated as errors
make[4]: *** [/usr/src/linux-headers-4.19.0-6-common-rtcds/scripts/Makefile.build:315: /opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.o] Error 1
make[3]: *** [/usr/src/linux-headers-4.19.0-6-common-rtcds/Makefile:1534: _module_/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom] Error 2
make[2]: *** [Makefile:146: sub-make] Error 2
make[1]: *** [Makefile:8: all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-6-rtcds-amd64'
make: *** [Makefile:28: all] Error 2

We don't know how to deal with these error messages. This did not happen last year, so this might have to do with the change in fb1 or our cds setup. Chris and/or Jamie, please help.

  17377   Sat Dec 31 20:00:03 2022 ranaSummaryCalibrationETMY actuation strength cal with 5 lines
  1. how much frequency dependent variation in the transfer function do we expect? Are there resonances in the mechanical suspension cage or the violin modes?
  2. it would be interesting to make the same TF, but from counts to coil current, and see if the variation is there. I don't expect to see much variation in the electronics, but there might be something. In principle, we can just measure the voltage at the satellite box, but the coil cable's capacitance and the coil inductance make for some wiggle. I think the resonant frequency ought to be ~ 100 kHz, but perhaps there are some wiggles due to frequency response in the AI filter or something.
  17376   Sat Dec 31 19:27:32 2022 PacoSummaryCalibrationETMY actuation strength cal with 5 lines

Calibrated ETMY actuation strength using ALS. Attachment #1 shows the result, in close agreement with this previous measurement and a combined uncertainty estimate of 0.88%. The data was taken with 5 oscillators on, at slightly different strengths than with the ITMY run, and the actuation was on ETMY.

The ETMY actuation strength is

10.843e-9 / f^2 +- (0.88)% [m/count]

Note: gpstimes for raw data are 1356490036 to 1356495400 (a little bit over an hour and a half).

Attachment 1: ETMY_cal.pdf
  17375   Fri Dec 30 12:53:47 2022 KojiUpdateGeneral40m avoided the power outage

Received the campus power outage this (Dec 30, 2022) morning.
- ELOG is still up
- 6 CDS machines are up
- Vacuum system and pressure all look good

I believe this power outage happened on the other side of the campus and did not affect the 40m.

  17374   Fri Dec 30 11:38:45 2022 PacoSummaryCalibrationALS Calibration errors -- single arm actuation

Here are my thoughts on calibration errors. This applies to the single arm actuation calibration, but may easily be extended to calibrate the DARM residual noise for example.

According to the math in this post, there are four parameters whose estimates build the total calibration uncertainty: arm length, wavelength, loop gain, and beatnote fluctuation. Below is a table for how each is measured, what the sources of statistical versus systematic error are, how large each relative contribution roughly is, and how we may improve on them.

  Arm Length Wavelength ALS beat fluctuation AUX Loop gain
Current Estimate FSR scan using ALS, reference to POX/POY (11 MHz) sideband. NPRO Specification DFD + Phase tracker Swept sine
Statistical error Limited by scan range (e.g. DFD range) and resolution. No statistical error from specification Shot noise limited measurement ? Bendat Piersol Table 9.6 (depends on coherence)
Systematic error Limited by freq reference offsets (Marconi), and residual POS-PIT coupling NPRO half tuning range Flicker noise (electronics, other) Swept sine bias and servo drift (thermal, flicker)
Improvements More FSRs per scan at best possible resolution Iodine spectrsocopy Lower ALS residual frequency noise Higher AUX servo gain

Arm length


The arm length has been estimated before by locking the arm with the ALS beat, scanning the arm length and looking at the IR resonances. From the statistical uncertainty standpoint the limit seems to be number of measurable FSRs. Using these numbers, the statistical uncertainty comes to ~ 0.6%. Other attempts claim to have improved on this by almost an order of magnitude giving ~ 0.02%. Simply scanning over more FSRs should improve this as the usual square root number of measurements statistical error reduction.


Systematic error comes from the frequency referenced on this measurement (the Marconi 11 MHz sideband oscillator), nonlinearities in the mostly linear scan (e.g. POS to PIT coupling). I think it's safe to neglect frequency offsets > 1 Hz because of the Rb clock reference and the Marconi's own calibration. I'm not sure about the POS to PIT coupling magnitude and whether F2A filters are helping here, but offset scan nonlinearities should distort the FSR nonuniformly and this error may have sneaked into the statistical estimate above. From the posts referenced above,  the scan result seems extremely linear, but repeating the measurement and plotting the residuals may give an accurate estimate of the nonlinearity. I think either of the systematic errors discussed here should be below or around the ppm (0.0001%) level, but this should be confirmed.



If we use the NPRO specification Mephisto's wavelength is 1064 nm and there is no statistical error.

If on the other hand we do iodine absorption spectroscopy, we may be able to see ~ 4 lines throughout the 30 GHz tuning range of the NPRO. Fun fact: 30 GHz correspond to 1 cm-1 (inverse centimeter). Assuming we can scan our laser with a 0.01 cm-1 resolution, it may be possible to estimate the absolute wavelength to 10 better than any line center. The ATLAS of iodine spectroscopy gives strong absorption lines around 532 nm to 0.001 cm-1, or 0.00001% accuracy. A simple Doppler broadened absorption should improve this further.


If we use the NPRO specification the systematic error comes from the number of known significant figures ~ 0.047 %. A slightly better estimate comes from the Prometheus model with a frequency doubled output hitting near the P 83(33-0) line of iodine, at 18787.814 cm-1. This gives a nominal wavelength of 532.259 nm, or 1064.518 nm on the seed. Because the tuning range is 30 GHz, our systematic error may be +0.03 nm - 0.07 nm from 1064.52 nm. Taking the median of 0.05 nm, the relative systematic error from the Nd:YAG specification is 46.9 ppm = 0.0047%.

If on the other hand we do iodine spectroscopy, the systematic error will be dominated by the residual shifts on the iodine vapor, which are negligibly small compared to the Doppler broadened lines. They might add sub-ppm uncertainty to the absolute calibration.

Beat fluctuations


The error in estimating beatnote fluctuations is statistically dominated if our beat detection is shot noise limited for example. Other stationary noises with power law spectra decaying faster than 1/f are subject to this effect. The allan deviation discriminates the timescales at which our measurement is dominated by statistical error. Currently our calibration lines have SNR of 10 to 100. Averaging seems to be limited to ~ 100 second timescales, so the statistical error on these measurements is ~ 0.1 to 1.0 %.


As suggested in the above, the allan deviation discriminates the statistical dominated timescales for this measurement. There is a correspondence between noise spectra and allan deviation, so we should be able to point out what noises contribute to systematic drift in our ALS noise budget.

Loop gain


Invoking Bendat and Piersol, Table 9.6 gives the statistical estimate of loop gain estimate with coherence gamma, and n_avg number of averages. Because of our resonant OL gain filters, assuming G ~ 100 there, and high coherence on the OLTF measurement so gamma ~ 0.9, with 12 averages we should get a relative loop gain error of 9.8%.


Also from B&P, we should estimate how biased our TF is. This depends on delays, bandwidths, measurement device noises, etc. Furthermore, the analog electronics in the AUX servo should drift, but we neglect this contribution for now. A simple bias estimate (eq 9.75) tells us that the coherence is biased by the number of averages such that in our estimate above the unbiased coherence is roughly 0.897. This means our systematic contribution from TF bias is ~ 0.17 %.

We should remember that in the case of loop gain, the total error (systematic + statistical) gets an extra suppression factor of the order of the loop gain itself. Radhika's resonant digital gain filters should easily allocate 40 dB (or ~ 100) on every calibration line such that our total calibration error drops to the 0.1% level.


  • The main calibration error (at the 1% level) seems to be from the ALS beat frequency. We can simply crank the SNR up, but we should work on the ALS relative stability. I think the low frequency end of the ALS residual frequency noise is currently limited by DFD... I wonder if we can improve on this by implementing a digital PLL (e.g. using a Moku)
  17373   Wed Dec 28 19:50:06 2022 PacoUpdateCDSAnother CDS crash -- restored by model restart

Stopped by lab today. Found all suspensions undamped (even though watchdogs never tripped), same symptom as CDS crash from earlier this month. Fixed as per last ocurrence--- by restarting all models and burt restoring.

  17372   Thu Dec 22 15:52:48 2022 KojiSummaryDetCharSummary on the summary pages

[Tega Koji]

Last week, Tega gave me a brief introduction to the configuration of the summary pages. So this is the summary of the conversation.

1. General info resources

40m wiki https://wiki-40m.ligo.caltech.edu/DailySummaryHelp
40m wiki https://wiki-40m.ligo.caltech.edu/40mLDASaccount
40m git lab https://git.ligo.org/40m/40m-summary-pages

2. How the frame files are transfered

The frame files are created in /frames on fb1. ==> If the frame files are not found on fb1, it's the problem of FB/CDS.
This directory is exported to nodus (as /frames) via NFS. ==> If the frame files are not found on nodus (i.e. /frames is not found), it's the NFS problem between fb1 and nodus.
rsync executed on LDAS comes to nodus to pull the files to /hdfs/40m on LDAS. ==> If the frame files are not found on ldas, it's the rsync problem. We are not controllying this file transfer. Contact with Dan Kozak

3. How to get into LDAS

Look at the LDAS account wiki page on the 40m wiki. For me "ssh -J" approach didn't work. So I used "multi-step login", starting from "ssh albert.einstein@ssh.ligo.org"

4. How the proess is running

This summarizes the workflow very well: https://wiki-40m.ligo.caltech.edu/DailySummaryHelp#Technical_info

I am still not sure how the main script "gw_daily_summary_40m" is running every 30min as well as gw_daily_summary_40m_rerun.
Otherwise, the following scripts are running via crontab of the 40m account
0,30 * * * * /home/40m/DetectorChar/bin/plot-summary-job-duration ~/public_html/detcharsummary/summaryDiag.pdf
5,35 * * * * /home/40m/DetectorChar/bin/checkstatus
6,36 * * * * /home/40m/DetectorChar/bin/plot-temperature
7,37 * * * * /home/40m/DetectorChar/bin/pushnodus
27 18 * * * /home/40m/DetectorChar/bin/cleanLogs

The produced files are not in /home/40m/public_html/detcharsummary , the data processing has a problem.
If the files are there but not pushed to the 40m (by pushnodus), the file transfer has an issue.

  17371   Wed Dec 21 12:38:32 2022 ChrisUpdateOptimal ControlIMC alignment controller testing

Three additional mode cleaner alignment controllers were tested Sunday night (remotely). They were run in tandem with the (recently improved) standard controller. Each test consisted of five minutes with pitch alignment uncontrolled, five minutes with the standard controller only, and twenty minutes with both controllers enabled.

GPS times for each phase of testing were the following:

  1. slug_functional
    • Open loop 1355466269
    • Closed loop 1355466579
    • Policy 1355466987
  2. slug_hippocamp
    • Open loop 1355468210
    • Closed loop 1355468520
    • Policy 1355468849
  3. slug_hippocamp_slow
    • Open loop 1355470093
    • Closed loop 1355470403
    • Policy 1355470855
  17370   Wed Dec 21 12:35:49 2022 ChrisConfigurationCDSTiming trigger test

While recovering from the power outage, I took the opportunity to try having the timing system trigger on the rising edge of the 1 PPS signal from the GPS receiver (rather than the falling edge, as it had been doing since before the CDS upgrade). This was done in order to eliminate a timing offset between the clock used by the ADCs and the IRIG-B timestamps from the Spectracom boards. It was successful in that regard, and cleared the timing errors seen in the IOP statewords on most of the front ends.

The two exceptions were c1lsc and c1sus, where something is broken with the DuoTone readbacks. The attached plot shows the DuoTone signal in the last channel of ADC 0 on c1x01 (working normally) vs c1x02 and c1x04 (busted).

However, this change apparently also had some unexplained effect on the way the c1sbr model runs. There were frequent CPU time overruns and IPC errors. So on Sunday afternoon I reverted to the falling-edge trigger. This caused the timing errors to return, but allowed c1sbr to run normally.

Attachment 1: duotone.png
  17369   Wed Dec 21 12:18:44 2022 PacoSummaryLSCFPMI locked, but FPMI BHD not locked

[Yuta, Paco]

We tried restoring the FPMI BHD readout from yesterday but failed. Below is a summary of what we did.


  1. Align arms, MICH and LO (using ITMY single bounce).
  2. Lock both CARM and DARM with POX/POY to restore the "electronic" FPMI.
  3. Lock MICH with REFL55_Q.
  4. Handoff DARM to AS55_Q and CARM to REFL55_I.
  5. Lock LO_PHASE using BH55_Q
  6. Balance BHD_DCPD to remove offset in BHD_DIFF
  7. Measure the C1:LSC-BHDC_DIFF_OUT / C1:LSC-AS55_Q_ERR ratio to get the DARM content in BHD DIFF.
  8. Attempt DARM control handoff from AS55_Q to BHDC_DIFF  --- this step didn't work today despite our several attempts.

We found LO fringe alignment to be really important, as sometimes we would try to calibrate the DARM content of BHD DIFF and found almost no coherence between AS55_Q and BHD_DIFF, but after realigning the coherence was increased and the lock was better. Another difference with respect to yesterday was the sign flip implied by the measured ratio from step 7.

Calibrated FPMI noise spectra

In anticipation to restoring FPMI BHD, we took a calibrated FPMI noise spectra (error and control point). The saved diaggui template that produces Attachment #1 is on /cvs/cds/rtcds/caltech/c1/Git/40m/measurements/LSC/FPMI/FPMI_calibrated_noise.xml Our calibration was based on sensing matrix measuring the DARM content on AS55_Q which was 1 / (2.617 * 3.64e11 counts/m) =  1.0497e-12 m/count, and the (balanced) ETM plant = 10.91e-9 / f^2 m/counts.

Next steps

Sadly we couldn't take a FPMI BHD calibrated noise spectra, but things to look into next time are

  • Take TFs for FPMI CARM, DARM and MICH loops. We skipped this today, perhaps wrongfully so.
  • Measure the FPMI sensing matrix to check demod phases and optical gains (related to the above).
Attachment 1: FPMI_calibrated_noise_20221221.pdf
  17368   Tue Dec 20 23:32:58 2022 ranaUpdateASCWFS demodulation board modification - further study

That's great - I think this solution will be best. Having the PLLs actually gives us some problems - the square wave action in these demod boards because of the ECL drives pollutes the air with all the harmonics.

In the future, it would be best to get rid of these boards and just use the new aLIGO boards with a direct LO feed.


I played with the PLL bit more today to understand the issue. From what I understand, the following is the summary:


Second harmonic generation using mixer and bandpass filter

  17367   Tue Dec 20 18:27:14 2022 AnchalSummaryLSCFPMI locked, DARM calibration data taken, FPMI BHD locked!

[Anchal, Paco, Yuta]

FPMI locked with BHD readout!!!

Paco and I figured the repeatable recipe for locking FPMI today. The settings are saved as snapshot file. In short, we first lock fake FPMI using POX+POY and POX-POY and then locking MICH to REFL55_Q. We make sure there are no offsets in AS55Q or REFL55Q. Then we handoff CARM and DARM loops to 0.496*REFL55_I and 2.617*AS55_Q by changing gains on A and B paths simultaneously with tramp time of 5s. WE have pushed new measurements of CARM, DARM and MICH loop OLTFs to measurement repo.

We turned on 5 oscillators all sending calibration lines to ITMY at different frequencies to calibrate DARM readout. WE took this data for about 90 minutes and then decided to try locking FPMI with BHDC DIFF.

A simple handoff to 0.68*BHDC_DIFF at error point for DARM loop worked. The OLTF for DARM loop remained the same.

I need to run now, so more detailed elog will come later.

On another news, this was last day of Tega, a warm farewell to him.

Attachment 1: PXL_20221221_013126861.MP.jpg
  17366   Tue Dec 20 09:20:18 2022 PacoSummaryLSCFPMI locked and cal

[Anchal, Yuta, Paco]

Late elog (from yesterday) -- We locked FPMI, YAUX, and turned on calibration lines from gpstimes = 1355539386 to 1355539594 (lost lock because IMC unlocked angry)

We followed the steps in this elog and handed off from an electronic FPMI (POX, POY) to the RF one (REFL55 and AS55). We will continue this work today and try to finish a restore FPMI script to make it more robust.

  17365   Sat Dec 17 16:56:19 2022 AnchalUpdateASCWFS demodulation board modification - further study

I played with the PLL bit more today to understand the issue. From what I understand, the following is the summary:

Moku as VCO in WFS demod board PLL:

  • Moku input in VCO mode is actually limited to ~ +/-21 V contrary to what it says on the app (10 Vpp)
  • Whenever the VCO tuning signal goes beyond this range, Moku just ignores the input and sends a pure sine wave at the carrier frequency.
  • I think because of this rail point behavior, the PLL goes off to a bad mode where the VCO tuning signal from demod board rails to +15 or -15V, and thus Moku does nothing to correct for it.
  • I found a deterministic way of catching lock with Moku VCO:
    • With whatever carrier frequency, set the VCO slope to at least 1 MHz/V (10 MHz/V is better).
    • The VCO tuning signal most probably would rail to +15V or -15V.
    • Reduce +/- 15V supply, this moves the railing voltage with it.
    • When the voltage rails reach +/2 V, the PLL catches the lock.
    • Now slowly ramp back the power supply back to +/- 15V.
  • This way I was able to repeatedly catch the lock (see attachment 1), but of course, this can't be done when our board is mounted in the Eurocrat.
  • So I thought if I attenuate the VCO tuning signal by 20 dB and pass it through an SR560, I can control the VCO tuning signal amplitude. This approach however did not work. It was always required to reduce the +/- 15V supply to the board to catch the lock.
  • This makes me think that the phase detector chip AD9901 needs to be turned off initially or supplied with low voltage rails. I'm not sure why.
  • With this, I think we should scrap this idea of using Moku as VCO, it will be just too unreliable.
  • So we need to move to the possibility of feeding 22 MHz signals to the WFS demod board where VCO output goes.

Basically, we make our own PLL outside the board to generate 2 times LO frequency or we create 2 times LO frequency by second harmonic generation.

Moku:Pro as a frequency multiplier

This white paper from liquid instruments describes how Moku:Pro can be used as a frequency multiplier in the phasemeter app now. This functionality however has not been extended to Moku:Lab, so in 40m, we can not do this right now. If we get access to Moku:Pro, following will be required:

  • Send 11 MHz LO signal to Moku:Pro input 1 with phasemeter app on.
  • Select frequency multiplier option of 2 at the output 1. Set voltage to 2 Vpp and feed this signal to VCO RF out port on the modified demod board.
  • Leave VCO tuning port unconnected.
  • This way we would replace the internal PLL with Moku digital PLL. Moku's PLL can be run upto 10 kHz bandwidth and would be very robust for such use.

Second harmonic generation using mixer and bandpass filter

  • Split the 14 dBm 11 Mhz output from frequency generation box (I simulated this with benchtop function generator) using a splitter.
  • Send both outputs to ZP-3+ mixer (level 7).
  • Filter the output with SBP-21.4 band pass filter. Koji has measured this filter in 2013. See elog 40m/9010.
  • Amplify the output twice, first with ZFL-500HLN+ (20dB amplification), then with ZFL-1HADX (11 dB).
  • This setup provides enought output amplitude for the comparator chip AD96687 to generate clean ECL signal at 22 MHz without slipping. With only 20dB amplification, I could see the phase slip by 180 degrees enough times that the oscilloscope shows both outputs overlapped.
  • Attachment 2 shows the ICLK and QCLK signals generated by the board with this setup.

Next steps:

  • I'll modify one more board for sending in LO like this.
  • I'll test the demodulation performance of the board with LO input from the second harmonic generation.
  • Setup the optical path for AS WFS.
Attachment 1: MokuVCOAttempt.jpg
Attachment 2: SHGmethod.jpg
  17364   Fri Dec 16 22:06:55 2022 AnchalUpdateSUSLow noise state

I've turned off HEPA fan and all lights at:

PST: 2022-12-16 22:06:53.830911 PST
UTC: 2022-12-17 06:06:53.830911 UTC
GPS: 1355292431.830911

Tuned on HEPA again:

PST: 2022-12-17 14:39:57.974212 PST
UTC: 2022-12-17 22:39:57.974212 UTC
GPS: 1355352015.974212

I've turned off HEPA fan and all lights at:

PST: 2022-12-17 17:26:28.740675 PST
UTC: 2022-12-18 01:26:28.740675 UTC
GPS: 1355362006.740675

I also started WFS relief script at this time. This script would end in 600s from the above time.

  17363   Fri Dec 16 21:55:54 2022 AnchalUpdateASCWFS demodulation board modification attempt 2 - sort of working

[Koji, Anchal]

short version: We checked signals at different points in the circuit to make sense of why it was not working. We found out that teh comparator chip AD96687BR was not working as expected and was not converting the analog signal from our VCO or LO inputs to ECL. We tested 2 other spare board with same behavior. We decided to try replacing the comparator chip with a new one, and indeed that was the issue. The new chip was working as expected and we are able to get PLL lock on the board with Moku:Lab as the VCO. However, there are some issues that need to be ironed out. The PLL does not catch lock right away and we could not figure our a systematic way of reaching to a locked state. That smells fishy to me as in my experience, when PLLs work, they work very robustly. More analysis with data and figures will follow. For now, we have some hope that this can work.

There is always the option of not closing PLL loop and injected twice the demodulation frequency at the VCO port that we have access two. For this, I'll need to create a SHG unit for 11 MHz with 21.4 MHz BLP. I'll look into this solution as well.

  17362   Fri Dec 16 18:48:49 2022 yutaSummaryGeneralIFO alignment after power loss

[Paco, Yuta]

We have recovered the IFO alignment (FPMI and BHD) for the first time after the power loss on Dec 15th 11:30 AM PST.

PMC and IMC transmission
C1:PSL-PMC_PMCTRANSPD 0.7332153499126435 0.0004376671844386436
C1:IOO-MC_TRANS_SUMFILT_OUT 14370.22451171875 38.87278766402092

BHDC PDs with LO beam only
~>cdsutils avg -s 10 C1:HPC-BHDC_A_OUT C1:HPC-BHDC_B_OUT
C1:HPC-BHDC_A_OUT 111.07633819580079 2.916326545853983
C1:HPC-BHDC_B_OUT 96.85788955688477 2.4419271045522506

Arm transmissions
~>cdsutils avg -s 10 C1:LSC-TRY_OUT C1:LSC-TRX_OUT
C1:LSC-TRY_OUT 1.0163812279701232 0.02008742269699207
C1:LSC-TRX_OUT 0.9274496018886567 0.027689954466601815

MICH fringe with ETM misaligned
See Attachment #1

LO-ITMX single bounce fringe with ITMY misaligned
See Attachment #2

Attachment 1: LSC-AS55_Q_ERR_DQ_1355280066.png
Attachment 2: LSC-BH55_Q_ERR_1355280385.pdf
Attachment 3: Screenshot_2022-12-16_18-52-13_FPMIBHDaligned.png
  17361   Fri Dec 16 14:52:42 2022 PacoSummarySUSMC1 and MC3 coil dewhitening filters added, location corrected

I corrected the filter module location for 28 Hz ELP filter on MC1 and MC3 coil output filter banks to FM8 (from FM9). FM9 is always reserved for SimDW (which is simulated dewhitening filter and is supposed to be a copy of the dewhitening filter on the analog side). FM10 is also reserved for InvDW filter which performs the anti-dewhitening before DAC. This filter module, FM10, shoudl remain on always. When FM9 is on (SimDW), the analog dewhitening turns off and we get a flat digital response as well. When FM9 is off, the analog dewhitening is turned on. Nominal operation configuration right now is to not use the coil dewhitening and keep FM9 and FM10 on always.


  17360   Thu Dec 15 08:37:52 2022 JCUpdateDaily ProgressIMC Misalignment

PMC seems to have gotten very misaligned over the last 12 hours. I'm going in to align now.

Attachment 1: Screenshot_2022-12-15_08-37-16.png
  17359   Wed Dec 14 17:01:39 2022 PacoSummaryLSCFPMI in the post-cds upgrade era

[Paco, Anchal, Koji]

A possible long-hidden bug of MC2 dewhitening switching was found and fixed.
MC2 coil dewhitenings were always on without proper compensation.
MC1/3 also had a similar issue.
Now "SimDW" and "IncDW" filters were set on FM9 and FM10, and they properly deal with the DW state, which is switched by FM9.

We tried restoring FPMI configuration this afternoon. For this we tried the following:

1. Lock PSL to YARM (through MC2) using the CARM LSC filter.
    a. Input: 1 from POY11_I
    b. Output: -17.5  to MC2
    c. Gain: 0.009
    d. Locking FM: FM5 only
    f. Trigger: TRY with 0.3, 0.1 thresholds
    e. FM Trigger: FM1, FM2, FM3, FM6, and FM8
2. We lock XARM to PSL (through ETMX) using the DARM LSC filter.
3. A simple handoff of the error and control points didn't work at first.

    a. We decided to look at the actuation strength of MC2 relative to ETMY. By locking the YARM using POY11, we measured the actuation transfer functions on two control points ETMY and MC2  referenced to the YARM cavity. Our expectation was a flat response in the ETMY control point, and a scaled, nominally flat response on MC2 so the ratio between the two give us the right output gain.
    b. A first suprise was found when exciting at MC2; here we observed a steep frequency dependent response, which suggested the MC2 actuation was weaker by over an order of magnitude.... Since this didn't make sense, after a little investigation and Koji's help, we figured out the issue was with the MC2_COIL SimDW and InvDW filters! These filters were on FM7 and FM8, but their outputs were not affecting the state of the analog electronics DW filter! After reviewing the model and comparing against ETMY, we figured we should change them to FM9 and FM10. This change successfully addressed the bogus frequency dependence (which was just the oblivious electronic DW filter gain).

  17358   Wed Dec 14 12:37:20 2022 RadhikaUpdateALSXARM green laser lock debugging

On Monday I aimed to measure the transfer function of the x-arm AUX PDH loop while momentarily locked, with a Moku:Go. I re-aligned the XEND green beam input to the arm cavity with M1 and M2 steering mirrors. I got GTRX to ~1.4 and the TEM00 mode nominally locked (back to ~5 seconds of lock, like last time). Previously Paco and I had achieved transmission of 3, so there was still a good way to go in mode matching. 

However I noticed the backwards-propagating beam started to drift relative to the opening of the Faraday isolator (located after the shutter). During manual alignment the backwards beam cleared through the aperture of the FI, but around 5 minutes later it had drifted too high and the beam spot was visible against the FI body, missing the aperture. At this point transmission had dropped to 0, and I realigned the beam to clear through the opening. I tried to further increase transmission but the drift continued to occur within a few minutes of re-alignment. I double checked that there was no dithering of ITMX or ETMX. It seemed there was high residual motion of the ETM, but I was not sure how to decrease this (damping filters were on). I moved on to setting up the TF measurement and decided to return to alignment once the loop excitation was configured.

I chose to inject an excitation from the Moku at the error point of the PDH servo box. I set up the measurement from 100 kHz to 100 Hz, zoomed in around the loop UGF. I passed the mixer output / error signal (alpha) to a T-splitter and sent one copy to input A of an SR560, and routed the Moku excitation to input B. The summed output of the SR560 was sent to the PDH servo input (beta). I passed the second copy of the error signal (alpha) to the Moku, along with the servo input monitor signal (beta) from the PDH box. The Moku measured the transfer function alpha/beta to obtain G_OLG. 

I returned to align the green beam and recovered flashing of the TEM00 mode. However when I closed the loop (with excitation), it didn't catch lock. I quickly reverted the loop back to its original state and confirmed that TEM00 locked for ~5 seconds. This made me think the excitation signal was too large relative to the error signal, so I reduced its amplitude to 500 mVpp. This still didn't recover the lock, and at this point the alignment had drifted again so I decided to wrap up. 


- Investigate alignment drift; confirm ITM/ETM motion within expected range
- Recover GTRX of ~3
- Calculate optimal excitation amplitude relative to error signal
- Inject excitation at control point if the previous step doesn't recover lock.

I am working remotely for the next week, so I can carry out these steps in January.


  17357   Tue Dec 13 23:49:17 2022 AnchalUpdateSUSLow noise state

I've turned off HEPA fan and all lights at:

PST: 2022-12-13 23:49:12.955214 PST
UTC: 2022-12-14 07:49:12.955214 UTC
GPS: 1355039370.9552

Turned HEPA back on:

PST: 2022-12-14 10:47:49.944161 PST
UTC: 2022-12-14 18:47:49.944161 UTC
GPS: 1355078887.944161

  17356   Fri Dec 9 23:44:14 2022 ranaSummaryASCMC WFS sensing matrix measurement

with the new output matrix, we repeated the diagonalization script that Anchal ran previously. In the attached plot you can see that as we successively apply offsets to the WFS1, WFS2, and MC_TRANS Pitch loops, there is the offset in the loop we offset, but there is no appreciable step seen in the other loops.

Maybe we could do better, but this is the best DC diagonalization I have ever seen in this system. So we should just keep it for now.

At some point, we should run this procedure for YAW as well, but not urgent.


Attachment 1: Screen_Shot_2022-12-10_at_6.43.38_PM.png
  17355   Fri Dec 9 21:54:40 2022 RadhikaUpdateASCMoku digital filter for low-frequency resonances (ALS/calibration)

[Radhika, Paco]

I modeled a digital filter for adding a resonance at a desired frequency (Q~100), with a complex-conjugate pole pair and 2 real zeros (2nd order system). Paco suggested I start with a 575 Hz resonance. I loaded the digital filter onto the Moku using the Moku python API (script at labutils/moku/mokuGoPro/mokuDigitalFilter.py). I tested the filter by feeding the Moku a 2 Vpp signal around 575 Hz and looking for some noticeable gain - however the signal passed though unchanged. There might be an additional Moku command for enabling the filter - I'll look into this.


- Debug deployment of digital filter to Moku:Go
- Test on preset low-pass filter, before custom filter
- Once successful, add multiple resonances helpful for calibration
- Deploy filters in xarm AUX-PDH loop
  17354   Fri Dec 9 18:32:11 2022 KojiSummaryASCMC WFS sensing matrix measurement

[Rana, Koji]

The IMC WFS pitch Output Matrix was recalculated based on a DC Sensing Matrix measurement.

The IMC and the WFS heads were realigned and the WFS offsets were reset. The WFS servo is running stably for ~1.5hrs now.

Using Rana's test with the optic offsets, the sensitivity of the sensors against the misalignment of each optic was measured. First of all, we accessed the recorded 900s data on Dec 9 2022 12:48:00 UTC (Attached 1). This DTT XML file is stored in /users/koji/221209/221209_IMC_WFS_PIT.xml

You can see the attachment that the foton style smoothing filter was used to reduce high freq noise above 0.1Hz.

Then the averaged values were read from "Cursor" tab (Attachment 2). This gave us this following sensing matrix.

Null to {WFS1P, WFS2P, MCTransP}
-36.7 +/- 90
401   +/- 200
-19.4 +/- 5
MC1 to {WFS1P, WFS2P, MCTransP}
2870 +/- 150
 910 +/- 150
1240 +/- 7
MC2 to {WFS1P, WFS2P, MCTransP}
  3950 +/- 200
-21700 +/- 490
  1210 +/- 13
MC3 to {WFS1P, WFS2P, MCTransP}
 -988 +/- 100
-7870 +/- 350
 1010 +/- 4
The inverse of this matrix is
           To MC1    MC2    MC3
From WFS1    1.2    1.0    -2.7
From WFS2    0.5   -0.4    -0.1
From MCT     5.0   -2.2     6.1

This is transposed for the MEDM output matrix. So the actual output matrix tried was

From WFS1  WFS2   MCT
     1.2    0.5   5.0   to MC1
     1.0   -0.4  -2.2   to MC2
    -2.7   -0.1   6.2   to MC3

We then individually tested the servo stability and the response to the input offset.
This matrix seemed indeed well diagnalized w.r.t the sensors. We injected the error signal offset in the MCTrans Pitch servo. This didn't reduce the IMC Trans indicating that the WFS1/2 were still as it was while the spot position was displaced. (very nice!)

The new matrix made all the pitch loops stable with negative gains (-0.1, -0.2, -0.5) together with the input gain slider of x1.0. The servo also worked together with the presence of the Yaw loops. Good.

The WFS1 gain was a bit too low. So we wanted to give 50% boost.
We decided to multiply the matrix elements by -0.3, increasing the servo GAIN fields by  -1/0.3. The resulting servo gain settings and the output matrix screen look like Attachment 3.

Then the IMC was aligned so that the reflection is minimized while the MC2 trans goes onto the center of the QPD.

Then the WFS offset script has been run with low and stable IMC Reflection DC (Attachment 4)

RXA Update 220109: I find the text based matrix hard to understand, so I am attaching the matrix I use to simulate this. Its the same as 'Sensing Matrix' that Koji has, but this one is scaled by an overall gain to account for the 200 counts actuation we put into the suspension actuators, and a minus sign as described above. Also its written in the usual way we represent vectors and matrices.
Attachment 1: Screen_Shot_2022-12-09_at_18.35.02.png
Attachment 2: Screen_Shot_2022-12-09_at_18.38.15.png
Attachment 3: Screen_Shot_2022-12-09_at_19.15.16.png
Attachment 4: Screen_Shot_2022-12-09_at_19.24.53.png
Attachment 5: Screen_Shot_2023-01-09_at_7.11.50_PM.png
  17353   Fri Dec 9 17:42:04 2022 KojiUpdateCDSNew donatella issues
  • MEDM video switches didn't work - "sh: 1: /opt/rtcds/caltech/c1/scripts/general/videoscripts/videoswitch3: not found"
    • This was fixed by modifying #! from /usr/bin/python to /usr/bin/python3
  • [IMPORTANT!] ezca* not found: ezcaread/ezcawrite/ezcastep/ezcaservo
    • This broke IMC WFS reied script

      This will start a relief servos for 600that can not be stopped once started
      Do you want to continue (y/n)? y

      Starting the 600 second relief servos...

      /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/reliefMCWFS: line 28: ezcaservo: command not found
      /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/reliefMCWFS: line 30: ezcaservo: command not found
      /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/reliefMCWFS: line 33: ezcaservo: command not found
      /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/reliefMCWFS: line 29: ezcaservo: command not found
      /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/reliefMCWFS: line 31: ezcaservo: command not found
      /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/reliefMCWFS: line 32: ezcaservo: command not found

      Done relieving

      hit any key to close

  • [IMPORTANT!] emacs editor does not work - "emacs: symbol lookup error: emacs: undefined symbol: malloc_set_state, version GLIBC_2.2.5"
  17352   Fri Dec 9 14:18:43 2022 AnchalSummarySUSIMC optics angular actuation calibration at DC

Also reply to: 40m/16125

I migrated the code used in 40m/16125 to our scripts git repo and used it to apply offsets to IMC optics and noticing the parabolic change in the transmission values. Fitting the data with parabola and using the calculations mentioned in the previous post, we get following angular actuation calibration at DC from the PIT/YAW alignment output channels (cts) to actual motion in (urad):

Optic and DOF Calibration constant at DC [urad/cts]
MC1 PIT 13.92(3)
MC2 PIT 20.6(2)
MC3 PIT 11.95(3)
MC1 YAW 12.85(3)
MC2 YAW 18.9(2)
MC3 YAW 13.62(4)

*Note that in the previous post, the radius of curvature of MC2 used was wrong and has been corrected in this calculation to 17.87 m taken from Gautam's thesis Table A.1

Due to lack of time, we ran test faster on MC2, hence more uncertainty in it's results. Also, during MC1 YAW test, lock for breifly lost which required me to manually throw away some data points, but it did not affect the quality of fit much. Please see attached the data plots and fit.

For calibration at AC, another test needs to be performed which I did not do right now. 40m/16125 also describes how to do that, so someone can repeat that in future.


It would be good if someone can post here the actuation calibration in radians, so that we can have a physical calibration of the sensing matrix in counts/radian.


Attachment 1: IMC_Ang_Act_Calibration.pdf
IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf
  17351   Fri Dec 9 13:18:57 2022 yutaSummaryBHDMICH BHD optical gain measurements at different LO phases, elliptic fit

[Yehonathan, Yuta]

Here's a plot using same dataset from yesterday, but x-axis in raw BH55_Q data, not calibrated into degrees in LO phase.
This way you are free from calibration error in BH55_Q data to LO phase.
Elliptic fit is done using least squares.
dphi is calculated using the following equation where (ap, bp) are the semi-major and semi-minor axes, phi is the rotation of the semi-major axis from the x-axis.


dphi gives you LO phase at zero-crossing.
For example, the top plot says that the sensitivity of BH55_Q to BS crosses zero at "-133.92 deg," which means BH55_Q+MICHdither can lock LO phase at -134 deg or 46 deg.
The top plot also says that the sensitivity of BHDC_DIFF to BS crosses zero at "127.45 deg," which means BHDC_DIFF sensitivity to MICH maximizes at 38 deg or 217 deg.
The middle plot says that the sensitivity of BH55_Q to LO1 crosses zero at "90.09 deg," which means BH55_Q+LO1dither can lock LO phase at 90 deg or -90 deg, and BH55_Q(no dither) can lock LO phase at 0deg or 180 deg (by definition).

Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/SensingMatrix/PlotSensMatBHDvsLOPhaseData.ipynb

 - Use also BH55_Q+LO1/AS1dither to scan around 90 deg.

Attachment 1: BHDMICHSensingMatixvsLOPhaseCombinedXYPlot.pdf
  17350   Fri Dec 9 10:08:54 2022 RadhikaUpdateASCYEND green alignment chronicles

Today I set out to align and lock the YEND green laser, and observe the expected PDH error signal and PZT control signal. 

- I took note of PDH servo knobs:

    - gain knob: 10.0
    - LO phase knob: 2.86
    - boost: on
    - inversion: -

- Disconnected PDH servo PZT output to break loop

- Scanned pitch and yaw of steering mirrors 1 and 2 [Attachment 1] and achieved transmission ~1.2.

- Re-engaged the loop and with TEM00 locked, and did fine adjustment of steering mirrors to maximize transmission to 1.4.

- At this point I broke the loop again to look at the PDH error signal and piezo control signal in an oscilloscope. The error signal had high frequency noise, so the SR560 was used to low pass it before sending it to the scope.

- Once I reconnected the loop and locked to TEM00, I noticed lots of noise in green transmission. Paco took spectra of GTRY and found it was line noise at multiples of 60 Hz. I checked if any BNC shields at the servo box were touching. I shifted the LO frequency from 213.12 kHz to 213.15 kHz, so that the modulation/demodulation was not an integer multiple of 60 Hz. However, these steps didn't get rid of the line noise. To be further investigated.

Next I plan to revisit the XEND AUX loop and try to reach higher lock stability. 

Attachment 1: IMG_3982.jpg
  17349   Fri Dec 9 05:04:45 2022 ranaSummaryASCMC WFS sensing matrix measurement

I made a script to toggle the offsets in the MC SUS so that we can see the resulting error signals in the MC WFS / MC-TRANS_QPD.

I ran it just before 5 AM local time Friday morning.

It goes in order and applies a 50 count offset to the pitch filter banks. During this test the input to the IMC WFS servos is set to zero, so that the integrators hold the mirror position in the aligned state.

I will analyze this 3x3 measurement and post the resulting sensing matrix soon. It would be good if someone can post here the actuation calibration in radians, so that we can have a physical calibration of the sensing matrix in counts/radian.

Attachment 1: Screen_Shot_2022-12-10_at_12.00.46_AM.png
  17348   Thu Dec 8 20:40:14 2022 AnchalUpdateASCWFS demodulation board modification attempt

Based on the previous two elog posts, Koji and I decided that we should use 11 MHz signal for arm cavity ASC and modify a spare WFS demod board to work at 11 MHz. This board LIGO-D980233, uses a PLL to lock the to LO input and generate I and Q ECL clock signals from it. For this purpose, it uses POS-XX minicircuits VCO. For IMC WFS boards the model number is POS-75 and with the board design, it can work for 18.75 MHz to 37.5 MHz modulation frequencies.

To make it work for 11 MHz, we have to swap this with POS-25 but that is not available for purchase anywhere. So Koji and I decided to use Moku:GO as a VCO and make connections to the pin holes on the board. Today, I modified a spare WFS board to make this possible. I added a right angle SMA connector to take in VCO output signal and a BNC connector to send out tuning signal. See attached photos for the details of this hack.

Then I went to 1X2 and tried on this modified board on a Euro crate empty slot. I used Moku:GO in a multi-instrument mode in which first instrument was a Waveform generator set to modulate from external input 1 at 6 MHz/V. The output RF level was checked on an oscilloscope and increased until I got about 9.5 dBm power at the output. The second instrument was just an spectrum analyzer to see if the test output from ICLK looks ok. I fed LO from a spare output port on RF distribution box for 11 MHz signal. I made sure to attenuate this signal to get 2 dBm LO signal which is the case for the WFS demod board LO input as well. 

This test however failed. I could not see any signal from ICLK or QCLK output. I then tried to use the same slot as the demod board for WFS1 is used and I still did not see any output on ICLK or QCLK. I split the VCO tuning signal coming from the board to see it on an oscilloscope and it was mostly noise of ~1 mV level. I then tried to check ICLK and QCLK on oscilloscope and saw that they had a huge offset of -1.7 V. I suspect some ground mismatch issue between Moku:GO and the demod board.

I decided to call it a day here.

I reset everything back to how it was on the rack and turned on IMC WFS again. It is working as usual keeping lock steady for atleast last 20 min that I have seen it.


Attachment 1: PXL_20221209_035720569.jpg
Attachment 2: PXL_20221209_035729233.jpg
  17347   Thu Dec 8 17:52:39 2022 yutaSummaryBHDMICH BHD optical gain measurements at different LO phases, RF+audio dither

[Yehonathan, Yuta]

Sensing matrix measurements at different LO phases were performed under LO phase locked to both BH55_Q and BH55_Q+MICH dither.
We confirmed that BH55_Q+MICHdither can lock LO phase to around maximum MICH sensitivity for BHD_DIFF.

Locking configuratons
 - MICH was lockied using AS55_Q feeding back to BS, at dark fringe. Notch at 311.1 Hz was turned on. C1:LSC-MICH_GAIN=-6 (lowered to reduce BS DAC saturation).
 - LO PHASE was locked using BH55_Q, feeding back to LO1. FM2, FM5, FM8 on. C1:HPC-LO_PHASE_GAIN=+/-2.
 - LO PHASE was also locked using BH55_Q+MICHdither. BS was dithered with C1:HPC-BS_POS_OSC_CLKGAIN=4000 at 281.768 Hz (2nd notch of ELP80 used for demodulation). Feeding back to LO1. FM5, FM8 on (no LF boost). C1:HPC-LO_PHASE_GAIN=+/-20.
  -- Note that we could not increase the dither amplitude more as BS DAC starts to saturate (we are using BS for MICH loop, sensing matrix measurement, and audio dither; see 40m/17343).

Sensing martix measurements
 - Lines are injected to BS @ 311.1 Hz with amplitude of 1000, LO1 @ 147.1 Hz and AS1 @ 141.79 Hz with amplitude of 5000.

Estimating LO phase
 - Estimation of LO phase was done in the same way described in 40m/17287. We used measured sensitivity of BH55_Q for LO1 at BH55_Q zero crossing (-1.42e9 counts/m) to estimate LO phase offset from BH55_Q zero crossing.
 - In BH55_Q+MICHdither case, LO phase was flipped using the following equation when C1:HPC-LO_PHASE_GAIN is minus (to have consistend LO phase dependence with BH55_Q locking. NEEDS CHECK).

LOphase = 180 - arcsin(BH55_Q/A)

 - Attachment #1 shows the sensitivity of AS55, BH55, BHDC_DIFF/SUM to BS (upper panel), LO1 (middle) and AS1 (lower), under LO phase locked to BH55_Q. The upper plot is the same plot as 40m/17287. As we can see, "0 deg" in the x-axis is not the optimal phase for BHDC_DIFF to have maximum MICH sensitivity. "0 deg" is the optimal point in terms of BH55_Q sensitivity to LO1/AS1, as we tuned the demodulation phase to maximize it.
 - Attachment #2 shows the same plot, under LO phase locked to BH55_Q+MICH dither. Sensitivity of BH55_Q to MICH crosses zero at round these measurements, as we are zero-ing it with this locking scheme. Around these LO phases, sensitivity of BHDC_DIFF to MICH is maximized as expected. Also, sensitivity of BHDC_DIFF to LO1/AS1 is minimized, as expected (assuming residual MICH offset and contrast defect are small).
 - Attachment #3 is the combined data from #1 and #2. Data points from BH55_Q locking are marked with "o" and those from BH55_Q+MICH dither locking are marked with "x" (they have larger uncertainties in LO phase). Both measurements are somewhat inconsistent in some channels (BS to BHDC_DIFF and LO1/AS1 to BH55_Q). Needs further investigation.
 - Dashed lines are from scipy.optimize.curve_fit using the following fitting function.

def fitfunc(x, a,b,c):
    return a*np.sin(np.deg2rad(x-b))+c

Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/SensingMatrix/SensMatBHDvsLOPhase.ipynb

 - Lock MICH with BHDC_DIFF under LO phase locked to BH55_Q+MICHdither
 - Estimate LO phase noise contribution to MICH displacement sensitivity
 - Improve LO phase loop
 - Try audio+audio dither
 - Move on to FPMI
 - Move on to 44MHz
 - Estimate the amount of residual MICH offset and contrast defect from these plots

Attachment 1: BHDMICHSensingMatixvsLOPhase1354581028.pdf
Attachment 2: BHDMICHSensingMatixvsLOPhase1354580582.pdf
Attachment 3: BHDMICHSensingMatixvsLOPhaseCombined.pdf
  17346   Thu Dec 8 16:21:40 2022 PacoSummaryCalibrationITMY actuation strength cal with 5 lines

[Anchal, Paco]

After debugging the hardware, on gpstime 1354422834 we turned on 5 cal lines on ITMY to test the ALS calibration for the single arm along with our error estimates.

Note: the YARM IR lock lasted > 8 hours, but the GRY transmission dropped twice during the evening and hopped back up, so the phase tracker jumped a couple of times.


YAUX laser was locked to the YARM through the analog PDH servo (UGF ~ 2 kHz), YARM was locked to the PSL with POY11 (UGF ~ 200 Hz), and the ALS phase tracker was set to output the beat frequency noise in Hz. HEPA was left on during this measurement. The oscillators were similar to previous instances: gains of 70@211.1Hz, 100@313.31Hz, 100@315.17Hz, 300@575.17Hz and 15@30.92Hz with appropriate notches on ETMY to avoid POY11 loop supression.


For YARM, the high bandwidth YAUX laser loop with transfer function G ensures that the relative laser frequency fluctuations correlate with the relative length fluctuations as:

\frac{\delta \nu}{\nu} = \frac{G}{1 - G} {\frac{\delta L}{L}}

Then, getting the magnitude of the YARM displacement at calibration frequencies is possible by knowing the arm cavity length, open loop gain, and absolute frequency (wavelength). The relative calibration error on the magnitude of the displacement is

\frac{\Delta \lvert \delta L\lvert}{\lvert \delta L \lvert} = \left[ \left(\frac{\Delta {L}}{L}\right)^2+ \left(\frac{\Delta {\lambda}}{\lambda}\right)^2 + \left(\frac{\Delta {{\delta \nu}}}{{\delta \nu}}\right)^2 + \left(\frac{\Delta \lvert G \lvert}{\lvert G \lvert(\lvert G \lvert - 1)}\right)^2 \right]^{1/2}

including the relative uncertainties in the YARM length, wavelength, and open loop gain. Interestingly, the loop gain term weighs proportionally less as G increases, so even if G = 100 (10), its relative error contribution would be < 1%. To estimate our total error, we assume the wavelength and YARM length are 1064.1(5) and 37.79(1), and add the frequency dependent values for G with 10% error. Finally, we use the rms ASD to estimate the relative error from the beatnote fluctuation measurement.

The measurement was done similar to other instances, taking the 'C1:ALS-BEATY_FINE_PHASE_OUT_HZ_DQ' timeseries (sampled at 16 kHz) and demodulating at the calibration frequencies above to get the mean YAUX laser frequency fluctuation and its uncertainty from the demodulated rms ASD.


Attachment #1 shows the raw timeseries, Attachment #2 shows the spectra around the cal lines, Attachment #3 shows the demodulated timeseries, Attachment #4 shows the final result for the 5 lines, including the tallied errors as detailed above.

ITMY actuation = 4.92(11) nm / count / f^2


We compared our results from Attachment #4 against a MICH referenced ITMY actuation calibration found here; which Yuta guess-timated a 10% uncertainty (gray shaded band in Attachment #4). An important correction came for the 575 Hz line, not just because the YAUX OLG is small but because a violin filter on ITMY LSC output has a 1.4475 gain bump. In fact we collected any additional digital gains from the ITMY output filters:

Output filter digital gains at cal lines (from foton)
30.92 Hz 211.1 Hz 313.31 Hz 315.31 Hz 575.17 Hz
1.00007 1.0034 1.0101 1.01017 1.4475


  • Consider moving the 575 Hz line to avoid additional digital gain, but try to remain at high frequency.
    • Maybe here we can use the resonant gain MOKU filters that Radhika is designing.
  • Setup a live loop gain calibration to reduce the uncertainty for the high frequency cal line.
    • We can also just grab GTRY (transmission) as a proxy for optical gain and use for budgeting.
  • Work on setting up constraints for error mitigation based on allan deviation of the beatnote and PDH nonlinearity.
  • Move this to FPMI or some other lock configuration
Attachment 1: raw_timeseries.pdf
Attachment 2: als_beat_cal_spectra.pdf
Attachment 3: demod_timeseries.pdf
Attachment 4: ITMY_cal.pdf
  17345   Wed Dec 7 16:21:05 2022 yutaSummaryBHDImproved MICH BHD alignment

[Yehonathan, Yuta]

We found that moving AS1 in yaw improves power on ASDC and AS55.
We compensated this move with AS4 and SR2 to keep the BHD fringe (ITM single bounce and LO beam fringes ~600 counts in amplitude at BH55).
We have also aligned BHD CCD camera to avoid clipping on a lens just before the camera (all the other optics on ITMY table remain untouched).
After the alignment, MICH BHD sensing matrix were measured with new C1CAL model (40m/17339) under the following conditions.
 - Locked MICH with AS55_Q at dark fringe. Notch at 311.1 Hz was turned on.
 - Locked LO PHASE with BH55_Q with C1:HPC-LO_PHASE_GAIN=-2, using LO1.

Sensing matrix with the following demodulation phases (counts/m)
{'AS55': -161.16488964312092, 'BH55': 162.57275834049358}
Sensors      BS @311.1 Hz           LO1 @147.1 Hz           AS1 @141.79 Hz           
AS55_I       (-0.19+/-1.45)e+07    (-0.26+/-2.43)e+06    (+0.35+/-2.39)e+06    
AS55_Q       (-1.74+/-0.02)e+09    (+1.61+/-8.31)e+06    (+1.08+/-8.59)e+06    
BH55_I       (+3.01+/-0.17)e+09    (+3.20+/-9.59)e+07    (-3.67+/-9.46)e+07    
BH55_Q       (-6.77+/-0.45)e+09    (+1.09+/-0.17)e+09    (-1.22+/-0.18)e+09    
BHDC_DIFF    (-8.41+/-4.81)e+08    (-1.26+/-0.94)e+08    (+1.38+/-1.03)e+08    
BHDC_SUM     (-2.75+/-9.14)e+07    (+1.18+/-1.13)e+07    (-0.97+/-1.02)e+07  

AS55_Q optical gain to MICH and BH55_Q optical gain to LO phase was improved by ~45%, compared with previous measurements (see 40m/17287).
The value for AS55_Q is consistent with the free swing measurement as attached.
SENSMAT part of c1cal seems to be working fine.

Attachment 1: LSC-AS55_Q_ERR_DQ_1354479181.png
  17344   Tue Dec 6 17:40:13 2022 KojiUpdateASCIMC WFS heads electronic feasibility test for using for Arm ASC

We have spare WFS demods in a plastic box along the Y arm. So you don't need to modify the IMC demod boards, which we want to keep in the current state.

  17343   Tue Dec 6 17:12:23 2022 yehonathanSummaryBHDLO phase control using audio (MICH and AS1) + RF

{Yuta, Yehonathan}

Today we lock LO phase using audio+RF method in two variants: AS1+RF and MICH(BS)+RF. We measure the TFs and find that AS1 variant has a UGF ~ 17Hz and MICH variant has a UGF ~ 32Hz.


1. We lock MICH in the usual way using AS55. ITMs are aligned to make AS port dark. We use a single bounce and optimize mode-matching with LO beam by minimizing the BHDDC-A signal.

2. Using the new BHD Homodyne phase control MEDM screen we first try AS1. We put an elliptic filter with 80Hz corner frequency on the DEMOD1 filter bank. We find that the notch of that filter is at 281.768Hz and this is where we put the AS1 dither line.

AS1 is dithered with 20000 counts. We optimize the DEMOD1 demodulation angle by dithering LO1 at 27Hz and minimizing the Q quadrature in diaggui. We find that 45 degrees is the optimal demod angle. We lock the LO phase with a gain of ~ 45 and take the OLTF (attachment 1).

3. Next, we use MICH degree of freedom to lock LO phase. We dither BS with the same frequency as before with 4000 counts. Higher counts seem to put some offset on ASDC. As before we optimize the DEMOD1 demod angle and find it to be 115deg. We lock LO phase with a gain of 20 and take the OLTF (attachment 2).


Attachment 1: Screenshot_2022-12-06_16-44-37_LOPHASE_OLTF_BH55_Q_AS1dither.png
Attachment 2: Screenshot_2022-12-06_17-10-47_LOPHASE_OLTF_BH55_Q_BSdither.png
  17342   Tue Dec 6 16:52:26 2022 AnchalUpdateASCIMC WFS heads electronic feasibility test for using for Arm ASC

I tested teh WFS demod board for possibility of demodulating 11 MHz or 55 MHz signal with it. It definitely has some bandpass filter inside as the response is very bad for 11 MHz and 55 MHz. See attached the ASD curves for the excitations seens on I and Q inputs of WFS1 Segment 2 when it was demodulated with a clock of different frequencies but same amplitude of 783.5 mVpp (this was measured output of 29.5 MHz signal from RF distribution board). See attachments 2-4 for mokulab settings. Note for 29.5 MHz case, I added an additional 10 dB attenuator to output 1.

The measurement required me to change signal power level to see a signal of atleast 10 SNR. If we take signal level of 29.5 MHz as reference, following are the responses at other frequencies:

  • At 11 MHz:
    • I: -92 dB
    • Q: -97 dB
  • At 55 MHz:
    • I: -75 dB
    • Q: -72 dB

Note that I and Q outputs are unbalanced as well for the two different demodulation frequencies.

This means that if we want to use the WFS demodulation boards as is, we'll need to amplify the photodiode signal by the above amounts to get same level of outputs. I stil need to see the DCC document of these board and if the LO is also bandpassed. In which case, we can probably amplify the LO to improve the demodulation at 11 and 55 MHz. THe beatnote time series for the measured data did not show an obvious sinusoidal oscillation, so I chose to not show a plot with just noise here.


Attachment 1: WFS1_SEG2_DEMOD_Test.pdf
Attachment 2: 11MHz.png
Attachment 3: 29.5MHz.png
Attachment 4: 55MHz.png
  17341   Tue Dec 6 15:59:46 2022 RadhikaUpdateALSXARM green laser lock debugging

[Radhika, Paco]

Paco suggested that alignment could still be the primary reason why the XEND green laser is not catching lock. With the xarm cavity aligned with IR, I adjusted the M1 and M2 steering mirrors for the green laser, looking at the REFL PD output in an oscilloscope. Paco joined and was able to achieve better mode matching by adjusting mirrors and rotating the half-wave plate. At this point, we could see TEM00 consistently flashing. Green transmission also reached a value of 3, from around 0.5 that I was able to achieve previously (this channel is not normalized).

We broke the loop to make sure the demodulated signal looked as expected, and indeed it resembled a PDH error signal. After reconnecting the loop (with the gain knob set to 3.5), Paco lowered the REFL PD gain by 3 stages and I was able to raise the gain knob to 8 without the servo saturating. I turned boost on and toggled the servo inversion until the laser started to hold lock for a few seconds. The piezo output signal looked reasonable at this point, without clipping on either end. 

After some final adjustments to the steering mirrors and the half-wave plate, the green laser can hold lock for around 5 seconds. However it's unclear why the loop isn't more stable, and more updates are to come. 

ELOG V3.1.3-