40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 346 of 346  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Typeup Category Subject
  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
Screenshot_2022-12-15_08-37-16.png
  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.

  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.

  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
MokuVCOAttempt.jpg
Attachment 2: SHGmethod.jpg
SHGmethod.jpg
  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.

Quote:

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

  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
  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.

  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.

  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
946926959.95

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;
                       ^~~~~~~~~~~~
                       raw_copy_to_user
/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 );
                          ^~~~~~~~~~~~~~~~~
                          remove_proc_entry
/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]
   out_remove_proc_entry:
   ^~~~~~~~~~~~~~~~~~~~~
/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.

  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

  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
Screen_Shot_2023-01-03_at_3.37.07_PM.png
  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
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
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

  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
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
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

  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
DACBE2CD-35EB-4314-92FD-71C5270A6961.jpeg
Attachment 2: 45D7AF8F-5955-4036-B8AE-D761C2838408.jpeg
45D7AF8F-5955-4036-B8AE-D761C2838408.jpeg
  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
SUS_Model_Changes.png
Attachment 2: MC1_INMATRIX.png
MC1_INMATRIX.png
  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
IMG_6465.JPG
  17391   Tue Jan 10 20:24:29 2023 AnchalUpdateASCWFS demodulation board 111B - Working as expected

I've completed the modifications on two WFS demod boards. This required replacing all 8 mixer ICs on each board. I also tuned each channel to get less than 2 mV offset on all of them.

I was able to complete testing the board SNo. 111B today. The results are attached. The test was done by feeding the board 22 MHz LO generated by frequency doubling. A signal at 11 MHz was generated using Moku:Lab at 1mVpp and then further attenuated by 10 dB to make a fair comparison with the previous testing of the IMC WFS board at 29.5 MHz. This board has the same response as the IMC WFS board at 29.5 MHz. I tested all four channels in the second plot.

I'll complete the testing of the second board SNo 112 B and then move on to setting up the optical path for AS WFS.

Attachment 1: WFS_Board_111B_Test.pdf
WFS_Board_111B_Test.pdf
  17393   Wed Jan 11 17:05:55 2023 AnchalUpdateASCWFS demodulation board 112B - Working as expected

The other modified board 112B has been fixed and tested now. See the results attached. The issue was in some malfunctioning OP284 which have been replaced by AD8672.

Attachment 1: WFS_Board_112B_Test.pdf
WFS_Board_112B_Test.pdf
  17394   Thu Jan 12 10:06:10 2023 PacoUpdateALSDFD discriminant calibration

[Paco, Anchal] Log from yesterday work around 1Y2 rack; note that while this work was ongoing, TT2 position drifted slowly and misaligned the IFO input over the course of less than an hour. I suspect the DB9 breakout board and temporarily present components noted below may have introduced a floating ground in 1Y2, making the TT coil drivers misbehave. To support this claim, we noted that after removing the breakout board the drift disappeared!


We calibrated the DFD discriminant as a function of RF input level. The configuration was as follows:

  1. Break out IQ demod board RF output (in the rear chassis on 1Y2), looking at Ch1 board outputs (for BEATX). The two differential outputs were broken into two BNCs (pairs 1,6 and 2,7 for Q and I respectively), and fed into the Moku:Lab. A Marconi 2023A was used as a VCO, with FM ext mode enabled and a FreqDVN (modulation slope) of 200 kHZ / Vrms (1 Vrms = 1.41 Vp = 0.705 Vpp). The FM ext input on the Marconi was sourced by the OUT1 of Moku:Lab, and the IQ demod outputs were connected to IN1 and IN2 on Moku:Lab.
  2. After measuring the TF using a swept sine, I verified that the frequency response was flat up to 150 kHz (Marconi cuts FM ext at 275 kHz), so I switched to the oscilloscope instrument and setup OUTPUT to a 211.1 Hz sine wave, 1.41 Vpp to dither the 40 MHz by +- 100 kHz.
  3. Using the arbitrary math function in Moku:Lab Scope, I computed the DFD output magnitude = sqrt(I**2 + Q**2), and measured its mean over 3 seconds.

The results are summarized in Attachment #1.

Attachment 1: xbeat_dfd.png
xbeat_dfd.png
  17396   Thu Jan 12 15:31:27 2023 RadhikaUpdateALSXARM green laser lock debugging

[Radhika, Anchal, Paco]

AUX PDH Loop Stability

Today I tried aligning the XEND green beam into the arm cavity. Using M1 and M2 steering mirrors, I reached a max transmission ~1.2 of TEM00. In this configuration there was a "donut" mode also flashing, with transmission exceeding that of TEM00. Scanning all 4 degrees of freedom, I couldn't get TEM00 transmission to exceed 1.2, or significantly suppress the other modes. Not great mode matching. (PD gain: 20 dB; servo gain: 10.0.) 

In an earlier conversation Paco had recommended I preamplify the green REFL signal with an SR560 before feeding it to the RF mixer. (For yarm this is done with an SR560 gain of 1000.) I did so and raised the gain on the SR560 until it overloaded (PD: 0 dB; SR560: 100). This didn't immediately improve the lock quality, but because alignment still needed work I wasn't surprised. 

Anchal suggested the laser mode might be distorted by some lenses further upstream. We noticed some vertical spreading/distortion of the green beam by the first lens after SHG. I adjusted the pitch of an IR steering mirror until it disappeared. We then used the irises by the entrance to the arm cavity to coarsely align the input beam with M1 and M2. This time, fine alignment brought green transmission to just under 4. After slightly adjusting the half-wave plate, green transmission peaked at 4. (This is the highest I've seen it - previous max was 3.) The final combination of PD gain, SR560 gain, and servo gain that maximized transmission and duration of lock was (PD: 10 dB; SR560: 20; servo: 4.0). At its longest, lock on TEM00 was maintained for ~10 seconds.

AUX PDH Loop OLTF

In parallel with above, I was trying to take an OLTF of the loop whenever it was temporarily locked. I set up the measurement configuration like in the previous ELOG (injection at error point). Like last time, the loop would not lock when summing the PDH error signal with the excitation. I confirmed this was true even when I turned off the Moku excitation output. Checking the summed signal output, the Moku was adding an offset to the error signal. Buffering the excitation with an SR560 solved this issue.

The locked mode was switching pretty rapidly during the time I tried to measure the OLTF, and I ended up moving onto trying to improve lock. I might return today to try to take a measurement - I'll post it here.

Attachment 1: IMG_4166.jpg
IMG_4166.jpg
  17397   Thu Jan 12 18:51:17 2023 PacoUpdateALSDFD and Phase tracker AM coupling

[Anchal, Paco]

We measured DFD AM coupling; it seems to be minimum at higher RF input and low modulation depths as expected.

To do this, we set up Moku:Lab for AM ext with a spare DAC channel (C1:BAC-SPARE_CH14_OUT) which we send a swept sine excitation using diaggui. We vary the carrier level, and the modulation depth (every time we changed the level, we run the phaseUGF.py script to allow the phase tracker to adjust its loop gain properly). Attachment #1 shows the results, showing the finite bandwidth effect of the phase tracker as well as the mean magnitudes of the AM coupling below 100 Hz. This measurement and the script live in

/opt/rtcds/caltech/c1/Git/40m/measurements/ALS/DFD_calibration/

What this means for ALS calibration:

It seems the residual AM coupling for a typical RF input level from our ALS beatnote corresponds to the couplings of ~ 2 Hz/V. This means that if the RF input level is fluctuating by 100mV, our residual beat frequency fluctuations only move by 200 mHz. This is not the case when the arms are locked... there the beat level stability is closer to 1 mV (so 2 mHz coupling to the phase tracker). Under previous SNR conditions, our lines are typically at a few 100 Hz of amplitude, with a noise floor comparable to a few 100 mHz (SNR ~ 100s), so AM coupling seems not to be statistically limiting for 0.1% calibration.

Next:

  • To further reject this residual coupling, it may be worth balancing the demodulated IQ amplitudes, by using the digital gains "C1:ALS-BEATX_FINE_Q_GAIN, C1:ALS-BEATX_FINE_I_GAIN".
  • For now, this effect (and its frequency dependence above 300 Hz) can probably be neglected for ALS calibration purposes.
Attachment 1: DFD_AM_coupling.pdf
DFD_AM_coupling.pdf
  17406   Thu Jan 19 20:35:54 2023 AnchalUpdateASCInstalled 2 flipper mirrors for handingl MC reflection beam to camera

Today I installed two flipper mirrors M3 and M4 (see attached photo) to create alternate route for MC reflection camera beam. Both these mirrors are Y1-1037-45S. In nominal operation where IMC is using the WFS, we will keep M3 upright and M4 flipped down. When using WFS for AS, M3 will be flipper down and M4 will be upright to save the camera from the high intensity MC reflection beam.

Note that everytime M3 is flipper and put back upright, the alignment into WFS would need to be tuned as the flipper apparatus does not come back to same alignment everytime. I centered the beams on the WFS heads today and zeroed RF offsets usingC1IOO_WFS_MASTER>!Actions>Correct WFS RF Offsets script. After this, the IMC WFS loops are working as expected atleast for last 15 minutes that I have monitored them. Hopefully, this will remain consistent.


Upcoming work:

  • Change the steering mirror that steers the beam to black hole to be a flipper mirror too as AS beam strength (measured when MICH was locked to bright port) is 0.3 mW and IMC WFS heads combined power is 0.5 mW in nominal operation, so we can not afford to dump any AS beam light.
  • Put flipper mirror M1 and fixed mirror M2 mentioned in 40m/17320 for steering AS beam to IMC WFS heads.
Attachment 1: PXL_20230120_041313615.jpg
PXL_20230120_041313615.jpg
  17407   Fri Jan 20 20:13:20 2023 AnchalUpdateASCInstalled 2 flipper mirrors for handingl MC reflection beam to camera

After discussions with Yuta, I figured that a better optical layout is possible which does not interfere with the existing IMC WFS path at all. So I reset the IMC WFS path today (and zeroed RF offsets again) and changed the MC reflection camera and MC reflection beam dump (black hole) position to create space for a flipper mirror that will pop up in the IMC WFS path and steer in the AS beam. New proposed path is shown in the photo in cyan. Red is MC reflection beam, yellow is IFO reflection beam and orange is teh AS beam that we will pick up using flipper mirror M1. Note that I found an intense 6.4 mW ghost beam coming out of the interferometer in between IFO refl and MC refl beams. This beam is shown in pink which I have dumped now. This beam was earlier not dumped. We will need to investigate more on the source of this beam and correct it in the next vent.

Attachment 1: PXL_20230121_035908170.NIGHT.jpg
PXL_20230121_035908170.NIGHT.jpg
  17408   Sat Jan 21 15:32:40 2023 AnchalUpdateASCAS WFS path nominally set

I've completed the beam redirection path for AS beam to WFS heads in a nominal way. By that I mean that all mirrors (M1, M2, M3, and M4) are now in their final positions and we will need to install one or two lenses to collimate the beam to match the mode that the WFS path is expecting as it has it's on the focusing lens before the photodiodes. For this last part, I think the fasted way would be to profile the beam and calculate the correct lens and position rather than trial and error as the beam intensity is very low for estimating the beam size by eye.

IMC WFS state: Flip M1 and M2 down.

AS WFS state: Flip M1 and M2 up.

Attachment 1: PXL_20230121_231740878.NIGHT.jpg
PXL_20230121_231740878.NIGHT.jpg
  17409   Sat Jan 21 18:01:06 2023 AnchalUpdateALSDFD and Phase tracker AM coupling

I took transfer function measurement of DFD AM coupling using noise excitation.


Noise excitation setup

Noise is injected using C1:BAC-SPARE_CH14_EXC using awggui which is filtered by a foton filter to simulate the real beatnote RF amplitude noise measured by taking quadrature sum of C1:ALS-BEATY_FINE_I_OUT and C1:ALS-BEATY_FINE_Q_OUT. See attachment 1.

The DAC output is connected to MP1 at CH1. MP1 is set to run in waveform generation mode with following settings:

 

  • Carrier frequency: 45 MHz
  • Carrier Level: 500 mVpp
  • No offset or phase offset
  • Amplitude modulation ON
    • Modulation slope: 100%/V
    • Source Input: Ch1

The AWGUI is set to excite C1:BAC-SPARE_CH14_EXC using settings mentioned in attachment 2.

With this setup, the RF amplitude noise is simulated with MP1 and DAC excitation.


Transfer function measurement

With AWGGUI running as mentioned above, I simply used diaggui in spectrum mode for channels C1:BAC-SPARE_CH14_EXC and C1:ALS-BEATY_FINE_PHASE_OUT_HZ. The second channel is already calibrated into Hz, and the first channel is in counts. To convert it into voltage of amplitude fluctuation, I first converted DAC excitation to voltage by assuming 16 bit DAC with +/- 10 V range, this gives conversion constant of 10/2**15 V/cts. Then since MP1 is doing 100%/V AM modulation, for 500 mVpp RF level, this means 0.25 V/V AM modulation. Multiplying these two together gives, 7.6294e-5 V/cts. I put this number in teh diaggui calibration for C1:ALS-BEATY_FINE_PHASE_OUT_HZ.

This created the transfer function measurement attached in attachment 3.

The measurement resulted in roughly 2kHz/V AM to frequency coupling in DFD + phase tracker setup. The previous measurement with coherent sinusoidal excitation was exactly a factor of 1000 less than this, so I believe I might have made some error in calibrating or there could be an error in the previous elog. Please check my calculations. But a solid thing to note is the coherence measured below 1Hz. I'll do more sophisticated analysis on weekdays.

I also think that coherence was low because of low excitation. We should redo this test with more noise power to get good coherence in all frequency band to have good idea of what would happen to ebatnote RF amplitude noise at all frequencies.


Mon Jan 23 11:47:23 2023 Adding Attachment 4:

I realised that with the noise excitation setup set to mimic real beatnote amplitude noise with very low frequency noise as it is seeded with Moku:Pro, the measured frequency noise by the DFD+Phase Tracker setup at C1:ALS-BEATY_FINE_PHASE_OUT_HZ is an indicator of how much RF amplitude noise of beatnote contribute to the frequency noise measured by DFD+Phase tracker. Attachment 4 is the spectrum measured during this measurement.

Attachment 1: BeatYRFAmplitudeNoiseASDwithSimulation.pdf
BeatYRFAmplitudeNoiseASDwithSimulation.pdf
Attachment 2: AWGguiSettingsForSimulatedRFAMNoise.png
AWGguiSettingsForSimulatedRFAMNoise.png
Attachment 3: DFD_AM_to_Hz_Coupling_upto_0p1Hz.pdf
DFD_AM_to_Hz_Coupling_upto_0p1Hz.pdf DFD_AM_to_Hz_Coupling_upto_0p1Hz.pdf
Attachment 4: DFD_Phase_Tracker_Noise_Due_To_Amplitude_Noise.pdf
DFD_Phase_Tracker_Noise_Due_To_Amplitude_Noise.pdf
  17411   Mon Jan 23 16:31:23 2023 ranaUpdateALSDFD and Phase tracker AM coupling

Both the TF measurement and the noise measurements are useful, but the nosie measurement is much more meaningful. Since we expect the main coupling to be incoherent, what we really want is a noise budget style measurement:

  1. Measure the FM noise spectrum with only a single sine wave into the Moku.
  2. Same as #1, but with the AM noise added as you already did.
  3. Estimate the noise budget contribution by doing PSD subtraction, and then scale that by the excitation magntiude. This will be the contribution of beat amplitude noise to the measured calibration.
Quote:

I took transfer function measurement of DFD AM coupling using noise excitation.

  17412   Mon Jan 23 20:50:58 2023 AnchalUpdateASCAS WFS path beam profiled

I measured the expected beam profile by WFS photodiodes by measuring the beam when mode cleaner was unlocked from the point where beam is picked for WFS. See attachment 1 for beam details. z=0 is the point in the path where AS beam will merge.

For measuring the beam profile of AS beam, I had to focus it using a lens. I picked up a 360.6 mm ROC lens and placed it at z=-67 inch point. Then I profiled the beam at some comfortable section of the path and fitted it. with reverse z-axis. Using this method, I can place the lens back and obtain the original beam back. Attachment 2 shows this fitting process and identification of the original beam profiles. I plotted the AS beam profiles again in attachment 3 and saved them for seeding mode matching effort later. Note that we don't want to be super accurate here, so I did not do any error analysis, just wanted to finish this fast. Also pardon me for the bad quality plots, I did not want to learn Matlab plotting to make it beautiful.

Note: There is significant astigmatism in both IMC reflection beam and AS beam. This could be due to beam going through far off-center on lens. Something to keep in mind, again this measurement is not ideal in terms of precision but this large an astigmatism could not be due to measurement error.


Next:

  • Identify correct len(s) and their positions
  • Align the AS beam to WFS heads
  • Test the full signal chain.
Attachment 1: WFSPathBeamProfile.pdf
WFSPathBeamProfile.pdf WFSPathBeamProfile.pdf WFSPathBeamProfile.pdf
Attachment 2: ASFocPathBeamProfile.pdf
ASFocPathBeamProfile.pdf ASFocPathBeamProfile.pdf ASFocPathBeamProfile.pdf
Attachment 3: ASPathBeamProfile.pdf
ASPathBeamProfile.pdf ASPathBeamProfile.pdf ASPathBeamProfile.pdf
  17416   Tue Jan 24 21:04:59 2023 AnchalUpdateASCAS WFS path beam profiled

I completed the mode matching calculation today and found good solution with 360.6 mm ROC PLCX lens at -1.2 m from z=0 point. I placed the lens there today and aligned all mirrors to get centered beam on both WFS PDs when the flipper mirrors are flipper up. This alignment would probably require tweaking everying we flip the mirrors as the flipper mirrors do not come back to same position usually.

I mounted the modified WFS boards 111B and 112B next to the whitening filter boards of existing WFS. Now to switch over, onewould need to transfer the 8 RF lemo cables and the 2 IDE ribbon cables.

I'm working on rtcds model to read AS WFS data and handle it separately. I'll keep a WPICS binaruy switch to switch between IMC WFS or AS WFS. I need to figure out some build issues on this work still.

 

Attachment 1: ASBeamFocusingLens.png
ASBeamFocusingLens.png
  17418   Wed Jan 25 10:02:47 2023 yehonathanUpdate Earthquake, MC3 watchdog tripped

We came this morning and noticed the FSS_FAST channel was moving very rapidly. Short inspection showed that MC3 watchdog got tripped. After reenabling the watchdog the issue was fixed and the MC is stable again.

There is a spike in the seismometers 8 hours ago and it was probably due to the 4.2 magnitude earthquake that happened in Malibu beach around that time.

  17420   Wed Jan 25 12:49:14 2023 RadhikaUpdateALSXARM green laser lock debugging

I returned the half-wave plates on the XEND table back to their original angles, and restored the loop configuration with the PDH servo box. I returned the PD gain to 40 dB (original setting), and set the servo gain knob to 6. This was the region of highest loop stability, with the lock holding for a few seconds (as before). The control signal on the scope did not look intuitive - the peaks of the control signal corresponded with zero crossings of the error signal. 

Paco encouraged me to retake transfer function measurements of the PDH servo box. The main takeaway is the PDH servo (boost on) has the expected frequency response at a gain setting of 3 or under, up to 100 mVpp of input. Attachment 1 shows the frequency response at a servo gain of 2, for varying input amplitudes. 

The rest of the bode plots correspond to servo gain of 4, 6, 8, and 10 (boost on). The saturation LED would turn on above a gain value of ~3.25, so these results can't be analyzed or interpreted. But it does seem like a steep, low-frequency jump is a signature of the saturated servo. This jump doesn't appear with 10 mVpp input, at least at or above 1 Hz. 

Attachment 1: XEND_PDHservo_boost_on_gain2.pdf
XEND_PDHservo_boost_on_gain2.pdf
Attachment 2: XEND_PDHservo_boost_on_gain4.pdf
XEND_PDHservo_boost_on_gain4.pdf
Attachment 3: XEND_PDHservo_boost_on_gain6.pdf
XEND_PDHservo_boost_on_gain6.pdf
Attachment 4: XEND_PDHservo_boost_on_gain8.pdf
XEND_PDHservo_boost_on_gain8.pdf
Attachment 5: XEND_PDHservo_boost_on_gain10.pdf
XEND_PDHservo_boost_on_gain10.pdf
  17422   Wed Jan 25 16:58:19 2023 AlexUpdateCamerasRecording CCD cameras

Thus far, the software needed for the Magewell video encoder has been successfully installed on Donatella. OBS studio has also been installed and works correctly. OBS will be the video recording software that can be interfaced via command line once the SDI video encoder starts working. (https://github.com/muesli/obs-cli)

So far, the camera can not be connected to the Magewell encoder. The encoder continues to have a pulsing error light that indicates "no signal" or "signal not locked". I have begun testing on a secondary camera, directly connected to the Magewell encoder with similar errors. This may be able to be resolved once more information about the camera and its specifications/resolution is uncovered. At this time I have not found any details on the LCL-902K by Watec that was given to me by Koji. I will begin looking into the model used in the 40 meter next.

  17424   Thu Jan 26 00:18:54 2023 KojiUpdateCamerasRecording CCD cameras

Connect any video signal supported by the adapter. Use Windows / Mac or any other OS. If it keeps complaining, contact Magwell support.

  17425   Thu Jan 26 15:56:30 2023 AnchalUpdateASC1X1 -5V sorenson tripped

[Yuta, Anchal]

Quote:

I mounted the modified WFS boards 111B and 112B next to the whitening filter boards of existing WFS.

The mounting of two additional WFS demodulation boards drew too much current on -5V rail which tripped the sorenson on 1X1. This was undetected until today. Because of this, the existing WFS boards were not working either. After investicgation to beam paths and PD to board signal chain, we found out this issue. We raised the current limit on -5V supply and it came back to 5V. This brought back functioning of the exisitng WFS boards as well. We increased the current limit slightly on +5V supply too as these boards take a lot of current on +/5 V rails. But we should do this more properly by knowing what current limit the supply is set to. We'll do this part in near future after reading the manuals/wiki.
IMC WFS loops are now working.

  17427   Thu Jan 26 18:20:43 2023 AnchalUpdatePEMHEPA Monitor setup using WFS BLRMS

I implemented the BLRMS on WFS1/2_I_PIT/YAW outputs and using there value, a HEPA state can be defined. I've currently set it up to use average of 10-30 Hz noise on WFS signals low passed at 0.3 Hz. For ON threshold of 100 and OFF threshold of 50, it is working for my limited testing time. To read HEPA state, one can do caget C1:IOO_HEPA_STATE. I've turned OFF HEPA for tonight's shimmer test. This is bare bones quick attempt, people can make the screen more beautiful and add more complexity if required in future.

Attachment 1: HEPA_MONITOR.png
HEPA_MONITOR.png
  17428   Thu Jan 26 23:33:19 2023 KojiUpdateLSCEP30-2 Epoxy bonding for Yuta

@OMC Lab
EP30-2 Epoxy bonding of V beam dumps for LSC PDs.

- Supplied 1"x0.5" glass pieces from the stock in the OMC lab.
- The black glass pieces were cleaned by IPA / Aceton / Aceton+Cotton Qtip scrub / First Contact
- 3 beam dumps are built. They require ~24 hrs to get cured.

=> Handed to Yuta on Jan 27, 2023

Attachment 1: PXL_20230127_053113856.jpg
PXL_20230127_053113856.jpg
Attachment 2: PXL_20230127_053145432.jpg
PXL_20230127_053145432.jpg
  17429   Fri Jan 27 11:26:31 2023 ranaUpdatePEMHEPA Monitor setup using WFS BLRMS

this is very exciting! Its the beginning of the task of reducing vast amounts of PEM data into human-useful (bite sized) info. Imagine if we had 60 Hz BLRMS on various channels - we would know exactly when ground loops were happening or disappearing.

  17436   Tue Jan 31 20:49:46 2023 AnchalUpdateALSMoku Phasemeter AM coupling and comparison

Model changes and addition of Moku Phasemeter

Today I setup Moku:Pro MP1 with phasemeter app to replace DFD + Phase tracker.

Phasemeter settings:

  • Both channels:
    • Frequency: Auto (Auto track frequency)
    • Bandwidth: 1 MHz
  • Advanced:
    • Freewheeling: ON
    • Single input: ON (Used for now, later the two channels will use different inputs)
  • Output for both outputs:
    • Signal: Freq offset
    • Scaling: 1.000 mV/Hz
    • Invert: off
    • Offset: 0.0000 V

Moku Input output settings:

  • In 1 and In 2:
    • AC: 50 Ohm
    • -20 dB attenuation: 4 Vpp range
  • Out1 and Out2:
    • +14 dB gain: 10 Vpp range

The phasemeter is set to autotrack the frequency with PLL bandwidth fo 1 MHz. The output of the phasemeter (frequency offset) is sent out through the output channels at 1mV/Hz rate. These are digitized at c1lsc ADC and are available as an alternative to phase tracker output channel. One can switch between the two ways of measurement by using C1:ALS-SEL_PHASE_SOURCE channel. See attachment 1 and 2 for the two mode options. For this, I modified c1lsc model today


Moku Phasemeter calibration

I used marconi to send 45 MHz RF output as -2 dBm level with internal FM modulation of peak 200 Hz at 211 Hz. This was used to calibrate the Moku Phasemeter outputs to set channels

C1:ALS-BEATX_MOKU_PHASE_OUTPUT_HZ and C1:ALS-BEATY_MOKU_PHASE_OUTPUT_HZ in units of Hz. This method is not very reliable as I do not know if marconi actually sent 200 Hz peak. The calculations from ADC conversion and moku slope of 1mV/Hz give similar numbers though. However, if we want to be accurate in our calibration project, more detailed calibration of these channels is required with a better technique. For now, I assumed that this value is good atleast to a 1% level.


AM coupling test and noise measurement

I followed the exact same setup as in 40m/17409 to create a RF signal using MP1 waveform generator which is AM modulated by awggui noise excitation to create similar AM noise as measured for BEATY RF output. The measurement can then take AM coupling transfer function measurements. Attachment 3 are the results of this measurement. In comparison to DFD + Phase tracker system, the transfer function is 2 orders of magnitude less. Even if my calibration of AM modulation is wrong, same calibration is sued for both transfer functions, so the difference measured is real. We are mostly measuring noise in this measurement as the coherence is also very low for all of the frequency range. See the 4th plot to see the inferred measurement noise of Moku phasemeter setup. Attachment 4 shows this data in comparison to data taken in 40m/17409 with DFD + Phase Tracker setup. Moku Phasemter setup provides roughly factor of 4 less noise in our calibration line frequency band.

Quote:

I took transfer function measurement of DFD AM coupling using noise excitation.


Noise excitation setup

Noise is injected using C1:BAC-SPARE_CH14_EXC using awggui which is filtered by a foton filter to simulate the real beatnote RF amplitude noise measured by taking quadrature sum of C1:ALS-BEATY_FINE_I_OUT and C1:ALS-BEATY_FINE_Q_OUT. See attachment 1.

The DAC output is connected to MP1 at CH1. MP1 is set to run in waveform generation mode with following settings:

 

  • Carrier frequency: 45 MHz
  • Carrier Level: 500 mVpp
  • No offset or phase offset
  • Amplitude modulation ON
    • Modulation slope: 100%/V
    • Source Input: Ch1

The AWGUI is set to excite C1:BAC-SPARE_CH14_EXC using settings mentioned in attachment 2.

With this setup, the RF amplitude noise is simulated with MP1 and DAC excitation.


Transfer function measurement

With AWGGUI running as mentioned above, I simply used diaggui in spectrum mode for channels C1:BAC-SPARE_CH14_EXC and C1:ALS-BEATY_FINE_PHASE_OUT_HZ. The second channel is already calibrated into Hz, and the first channel is in counts. To convert it into voltage of amplitude fluctuation, I first converted DAC excitation to voltage by assuming 16 bit DAC with +/- 10 V range, this gives conversion constant of 10/2**15 V/cts. Then since MP1 is doing 100%/V AM modulation, for 500 mVpp RF level, this means 0.25 V/V AM modulation. Multiplying these two together gives, 7.6294e-5 V/cts. I put this number in teh diaggui calibration for C1:ALS-BEATY_FINE_PHASE_OUT_HZ.

This created the transfer function measurement attached in attachment 3.

The measurement resulted in roughly 2kHz/V AM to frequency coupling in DFD + phase tracker setup. The previous measurement with coherent sinusoidal excitation was exactly a factor of 1000 less than this, so I believe I might have made some error in calibrating or there could be an error in the previous elog. Please check my calculations. But a solid thing to note is the coherence measured below 1Hz. I'll do more sophisticated analysis on weekdays.

I also think that coherence was low because of low excitation. We should redo this test with more noise power to get good coherence in all frequency band to have good idea of what would happen to ebatnote RF amplitude noise at all frequencies.


Mon Jan 23 11:47:23 2023 Adding Attachment 4:

I realised that with the noise excitation setup set to mimic real beatnote amplitude noise with very low frequency noise as it is seeded with Moku:Pro, the measured frequency noise by the DFD+Phase Tracker setup at C1:ALS-BEATY_FINE_PHASE_OUT_HZ is an indicator of how much RF amplitude noise of beatnote contribute to the frequency noise measured by DFD+Phase tracker. Attachment 4 is the spectrum measured during this measurement.

 

Attachment 1: ALS_DFD_Phase_Tracker_Mode.png
ALS_DFD_Phase_Tracker_Mode.png
Attachment 2: ALS_Moku_Phasemeter_Mode.png
ALS_Moku_Phasemeter_Mode.png
Attachment 3: MokuPhaseMeter_AM_Coupling_TF_and_Noise.pdf
MokuPhaseMeter_AM_Coupling_TF_and_Noise.pdf MokuPhaseMeter_AM_Coupling_TF_and_Noise.pdf
Attachment 4: PhaseMeasurementComparisonWithSimulatedRFsource.pdf
PhaseMeasurementComparisonWithSimulatedRFsource.pdf
  17437   Wed Feb 1 09:56:00 2023 RadhikaUpdateALSXARM green laser lock debugging

Last week I captured the closed-loop error signal of the xend green PDH loop. Green transmission was around 2.5, and the laser was locking for about 3 seconds every couple minutes or so. The servo gain knob was set to 5.0. Repeating this with higher transmission/locking time is worthwhile.

Attachments 1 and 2 are two separate lock durations, with x-axes spanning 1 second each. The trace of interest (error signal out of mixer) is Channel 1. Channel 2 contains the control signal outputted by the PDH servo box.

The error signal is contained in a slow-moving envelope at ~4.5 Hz, zoomed in with time cursors in Attachments 3 and 4.

Zooming in further, the error signal has a fast component at ~150 Hz (Attachments 5, 6).

Before taking these traces, I captured the green REFL signal and open-loop PDH error signal shapes (Attachment 7). This error signal linear range spans ~500 mVpp. From looking at this signal it seems like the closed loop contains excess noise.

From considering the above traces and loop calculations I can start to infer the closed loop shape and/or UGF, and what direction we need to move in to recover good locking.

Attachment 1: IMG_4255.jpg
IMG_4255.jpg
Attachment 2: IMG_4264.jpg
IMG_4264.jpg
Attachment 3: IMG_4261.jpg
IMG_4261.jpg
Attachment 4: IMG_4266.jpg
IMG_4266.jpg
Attachment 5: IMG_4257.jpg
IMG_4257.jpg
Attachment 6: IMG_4268.jpg
IMG_4268.jpg
Attachment 7: IMG_4274.jpg
IMG_4274.jpg
  17438   Wed Feb 1 11:52:13 2023 AnchalUpdateALSMoku Phasemeter AM coupling and comparison

I wondered if Moku could have lied about its noise measurement since the RF source was the same Moku device. To avoid this bias, today I repeated this measurement with sendinf RF from Marconi. Marconi settings were:

  • Carrier Frequency: 45 MHz
  • RF Level: -2 dBm
  • Mod AM ext DC: 90 %

The Marconi was fed noise from DAC output to match the measured BEATY RF amplitude like the previous posts: Attachment 1 shows AWGGUI settings required and attachment 2 shows the measured RF amplitude noise with the simulated source.

This source was then fed one by one to DFD + Phase tracker system (attachment 3) and then Moku Phasemeter setup (attachment 4). The phasemeter settigns were same as the previous post. Attachment 5 shows the two transfer functions of AM to frequency coupling on the same plot for comparison. Attachment 6 shows the comparison of frequency noise floor between the two methods on the same plot. In this measurement, I rechecked by DAC actuation calibration by measuring it directly. For Marconi AM modulation slope, I took into account the fact that the slope is in %/Vrms. I got it crosschecked with Paco this time. I think the calibration is correct. Moku phasemeter is indeed better by atleast 20 times in the frequency region of interest. The nosie floor is a factor of 3 less. I think this measurement clears Moku phasemter as the choice of frequency discriminator for calibration project. Any comments/opinions are welcome.

Attachment 1: AWGGUI_Setting.png
AWGGUI_Setting.png
Attachment 2: BeatYRFAmplitudeNoiseASDwithSimulation.pdf
BeatYRFAmplitudeNoiseASDwithSimulation.pdf
Attachment 3: DFD_AM_Coupling_TF_BW0p187493.pdf
DFD_AM_Coupling_TF_BW0p187493.pdf DFD_AM_Coupling_TF_BW0p187493.pdf
Attachment 4: MokuPhaseMeter_AM_Coupling_TF_BW0p187493.pdf
MokuPhaseMeter_AM_Coupling_TF_BW0p187493.pdf MokuPhaseMeter_AM_Coupling_TF_BW0p187493.pdf
Attachment 5: AMtoFrequency_Coupling_Comparison.pdf
AMtoFrequency_Coupling_Comparison.pdf
Attachment 6: PhaseMeasurementComparisonWithSimulatedRFsource.pdf
PhaseMeasurementComparisonWithSimulatedRFsource.pdf
  17439   Wed Feb 1 12:55:14 2023 RadhikaUpdateALSXARM green laser lock debugging

I reconnected the green REFL monitor channel and acquired its spectra when the laser was (mostly) locked. During the collection window, TEM00 would catch lock for a few seconds, drop, and catch again. As of today this is the longest the lock will hold. I'm uploading a screenshot for now but will replace with a proper .pdf spectra image.

There is a peak ~558 Hz and at its second harmonic. Additionally there is a less sharp peak at 760 Hz.

 

Attachment 1: xend_green_locked_final.png
xend_green_locked_final.png
  17440   Wed Feb 1 14:43:21 2023 JCUpdateVACFalse Nitrogen Leakage

Chub mentioned to Paco and I that the Nitrogen seemed to be losing pressure quicker than usual. After looking over the previous 4 months on Dataviewer, the pressure has a pretty consistent slope. I have ran into the issue of the neck of the N2 tank slighty leaking, so this may have been the issue. For now, there does not seem to be any significant or obvious problem.

Attachment 1: 40mN2.png
40mN2.png
  17442   Thu Feb 2 13:21:39 2023 RadhikaUpdateGeneralMephisto laser interlock

Today while aligning optics at the xend, my knee engaged the AUX laser interlock. I spent some time trying to disable the interlock, and I'm putting the solution here for mainly my reference: pull on the red interlock button. This shorts the two pins on the back of the Mephisto controller.

  17444   Fri Feb 3 12:50:47 2023 AnchalUpdateASCAS WFS model changes and phase calibration

Model and medm changes

After incrementally doing the model changes, I found out that the model was failing to build because of creation of a subsystem. If I just kept all divertor blocks out in the main model instead of in a single subsystem, the compilation works. Maybe the reason is because RCG can only take subsystems at base level which have top_names attribute. But I did nto test this, I just went with what works.

In summary, I added a new subsystem in c1ioo model called AWS (stands for Antisymmetric Wavefront Sensors). This subsystem and IOO subsystem receive teh WFS RF demodulated signals based on a single binary switch named C1:IOO-SEL_WFS_IMC_OR_AS. Value 0 connects the subsystem IOO to the inputs and value 1 connects AWS to the inputs. There is a switch on the left edge in the WFS screens now to select between the two.

Inside the AWS, the WFS I/Q phase rotation is done and then it goes into one of the two subsystems called AWS-XARM or AWS-YARM for using the AS for either XARM or YARM. THis is based on a single binary switch called C1:AWS-SEL_ARM_X_OR_Y. Value 0 selects output to XARM and value 1 selects output to YARM. There is a switch near top left of  C1AWS_XARM_WFS_MASTER.adl and C1AWS_YARM_WFS_MASTER.adl screens. I copied these screens from C1IOO_WFS_MASTER.adl, so they have same structure. See attachment 1. Any edits should be made to /opt/rtcds/caltech/c1/medm/c1ioo/master/C1AWS_XARM_WFS_MASTER.adl and simply run python opt/rtcds/caltech/c1/medm/c1ioo/master/createYARMWFSscreensFromX.py to create teh YARM screen from it.

Along with this, models c1scy and c1scx were edited also to take in IPC directly from c1ioo instead of going through RFM. We should phase out use of RFM eventually and directly connect all IPC connections with the ends.

First tests

[Anchal, Yuta]

After the model is up and running, we flipped the WFS path to use AS beam. I switched the 8 RF outputs of the WFS from IMC WFS boads to AS WFS boards and switched the IDC connectors to WFS. Attachment 2 shows teh photo in this flipped state. Then we misaligned both ITMX and ETMX. First simple test was to check if we see the YARM PDH error signal when YARM was flashing. And indeed we saw that on all 16 channels. So next we locked YARM and injected 311 Hz line with 300 counts amplitude at ETMY. We looked for this peak in the Q channels of WFS outputs and adjusted all phases to 0.1 degrees to minimize Q signal to the noise floor. For WFS2 case, teh SNR is bit higher due to more power than WFS1 and their phase angle might be adjusted to even better degree but we did not got for it.

Then I used C1AWS_XARM_WFS_MASTER.adl>!Actions>Correct WFS RF offsets button to remove offsets in all the RF demodulated signals. I have set this button to use /opt/rtcds/caltech/c1/Git/40m/scripts/RFPD/resetOffsets.py script.

At this point, we are ready to see if we have WFS sensitivity but I need to work on other projects today and Yuta and Paco took over interferometer for 60 Hz noise hunting.

 

 

Attachment 1: YARM_WFS_MASTER.png
YARM_WFS_MASTER.png
Attachment 2: PXL_20230203_211014833.jpg
PXL_20230203_211014833.jpg
  17445   Fri Feb 3 17:31:34 2023 JCUpdateGeneralVisit from Steve Vass

[Steve, Koji, JC]

Steve Vass came by today and was loaded with information. Here are a couple things we went over:
- Removal of the large optical table.
- Disconnecting the roughing pumps to prevent oil contamination. 
- Plexiglass End Enclosures
- TP1 maintenance Information


Removal of the large optical table. 

    Steve mention to us that there will be 2 machines that have to raise and rotate the optical. The optical table is 2 ft wide when rotated and this seems to easily give us clearance to get this guy out if we set it on piano dollies. The only issue we encountered is that we may have to disconnect the small power supply rack by 1X2 to make room for one of the machines that will rotate the table. If we manage to lift the table, slide it over to a more open area, lift again, and remove the dollies, then this may give us enough space for this machine and we won’t have to disconnect the power supply rack by 1x2. Overall, turning the table over on its side and maneuvering it into the aisle to go down the aisle along Xarm is the trickiest part. From there, we just have to find out where we are going to take this monster of an optical table.

Disconnecting the roughing pumps to prevent oil contamination
    

Disconnecting the roughing pumps to prevent oil contamination. 


    Steve let us know that he would disconnect to oil vacuum pumps after getting to your nominal vacuum pressure. This prevents these pump from possibly feeding oil into the system. Each of these pumps have an intentional leak vale that keeps the pressure above 300 mtorr. If the pressure get any lower, the pumps will begin to back pressure oil into the system.

Plexiglass Enclosures

  

   I asked Steve about some information on the end enclosures and PSL Enclosure. For the end enclosures, these were custom made. The film on the enclosure was added by people who do car window tinting. This film is not as strong as the plexiglass for the PSL Table. I have to look through Steve’s physical documents to find a receipt, or information of where he purchase the custom enclosure. As for the PSL enclosure, the film is actually imbedded/ combined with the plexiglass. This can withstand much more power than the end enclosures.

TP1 Maintenance
    
    Steve has sent TP1 and the controller for maintenance before. It seems like we need to do this roughly ever 4-6 years and the last time TP1 was shipped out for maintenance was in 2018. During this, Steve said he thinks he was shipped a temporary pump to use in the mean time while TP1 was being repaired. When there is an error with the pump, it will pop up on the controller as show in [elog 14189](https://nodus.ligo.caltech.edu:8081/40m/14189)Anyways, it seems like TP1 will have some issues coming up.

  17448   Sat Feb 4 14:55:25 2023 AnchalUpdateASCDC sensing matrix for AS WFS for YARM

Filter and scripts setup

I copied IOO_WFS1_I filter bank to AWS_WFS1/2_I/Q filter banks to copy the dewhitening and 60comb filters. Then I turned them on.

Similarly, I copied IOO_WFS1_PIT filter bank to AWS_YARM/XARM_WFS1/2_PIT/YAW filter banks. I created a generalised script to handle all WFS on/off.hold/onfromhold operations here. I also generalized toggleWFSoffsets script to be used for measuring DC sensing matrix.

DC sensing matrix measurement

This measurement folllowed the method used by Koji in 40m/17354. The measurement is pushed here. Ntoe that when using this method, while the test finishd in ~1000 seconds, it takes dtt >20 min to retrieve the timeseries data from DQ channels. Thisis weird because cdsutils.getdata does not have this lag. If anyone knows why this is the case, it would be helpful in making this method faster.

  • Locked YARM and misaligned ITMX and ETMX
  • Centered the AS beam on WFS using DC value.
  • Ran ASS on YARM to get to best aligned cavity state.
  • Unlocked YARM and ran C1AWS_YARM_WFS_MASTER>!Actions>Correct WFS RF offsets to zero teh offsets.
  • Locked YARM again and waited for >120 seconds.
  • Ran python /opt/rtcds/caltech/c1/Git/40m/scripts/AWStoggleWFSoffsets.py AWS BOTH -a YARM -t 120
    • Measurement start time: 04/02/2023 22:37:00 UTC
  • The offset values required for step response test above were determined by trying out values and making sure that transmission does not go down by more than 15%.
  • I had to leave by 3:30 pm, so I couldn't complete the analysis of measured data.I'll post data here soon.

 


Additions Sun Feb 5 18:06:54 2023:

Data analysis

I got the step response data using cdsutils.getdata and measured the sensing matrix and took and inverse with error propagation. Attachment 1 page 1 shows the raw data measured. Then the data was segmented based on step response time data and a linear fit is used to get linear trend of each channel in null configuration. This is used to remove bias later while measuring the step heights in each sensor. Page 2 shows this data. Page 3 shows final detrended and normalized step response data that was used to measure the sensing matrix. It came out to be:

                                                             YARM WFS DC Sensing Matrix

        ITMY PIT         ETMY PIT         ITMY YAW         ETMY YAW
   1.94 +/- 0.02    0.83 +/- 0.07   -0.15 +/- 0.04      1.3 +/- 0.1  to WFS1 PIT
   5.62 +/- 0.05      8.8 +/- 0.2     -0.2 +/- 0.1      2.5 +/- 0.2  to WFS2 PIT
  -0.43 +/- 0.03   -1.13 +/- 0.07    1.51 +/- 0.04     -0.9 +/- 0.2  to WFS1 YAW
  -1.42 +/- 0.05     -7.1 +/- 0.2      3.3 +/- 0.1    -19.5 +/- 0.4  to WFS2 YAW

Taking it's inverse with uncertainties supported matrix inverse function gave following output matrix to be used:

                                                         YARM WFS Estimated Output Matrix
        WFS1 PIT         WFS2 PIT         WFS1 YAW         WFS2 YAW
   0.628+/-0.022   -0.031+/-0.007   -0.027+/-0.020    0.039+/-0.004  to ITMY PIT
  -0.431+/-0.020    0.146+/-0.007   -0.002+/-0.018 -0.0099+/-0.0030  to ETMY PIT
  -0.086+/-0.031    0.078+/-0.010    0.728+/-0.029   -0.029+/-0.008  to ITMY YAW
   0.097+/-0.009 -0.0377+/-0.0030    0.126+/-0.008 -0.0555+/-0.0020  to ETMY YAW
Attachment 1: YARM_WFS_DC_Sensing_Matrix_Step_Response_Test.pdf
YARM_WFS_DC_Sensing_Matrix_Step_Response_Test.pdf YARM_WFS_DC_Sensing_Matrix_Step_Response_Test.pdf YARM_WFS_DC_Sensing_Matrix_Step_Response_Test.pdf
  17453   Mon Feb 6 20:44:34 2023 AnchalUpdateASCYARM WFS First Attempt - Success

I uploaded this measured output matrix to the YARM WFS model:

Quote:
                                                         YARM WFS Estimated Output Matrix
        WFS1 PIT         WFS2 PIT         WFS1 YAW         WFS2 YAW
   0.628+/-0.022   -0.031+/-0.007   -0.027+/-0.020    0.039+/-0.004  to ITMY PIT
  -0.431+/-0.020    0.146+/-0.007   -0.002+/-0.018 -0.0099+/-0.0030  to ETMY PIT
  -0.086+/-0.031    0.078+/-0.010    0.728+/-0.029   -0.029+/-0.008  to ITMY YAW
   0.097+/-0.009 -0.0377+/-0.0030    0.126+/-0.008 -0.0555+/-0.0020  to ETMY YAW

Then I played witht the signs of the gains and their values in the C1:AWS-YARM_WFS1/2_PIT/YAW filter banks until I saw a correct response for steps on ETMY and correction within 10-20 s.

I measured the OLTF of the loops with noise injection in each loop simultaneously. This test takes ~10 min. Except for the WFS2 YAW loop, all other loops behaved as expected with UGFs in WFS1 PIT 0.02 Hz, WFS1 YAW 0.04 Hz, and WFS2 PIT 0.035 Hz.

I left this state On for 1 hour and the YARM retained transmission. Attachment 2 shows the history.

Then I conducted another toggle test to see how the step response is. Attachment 3 shows the same results as last post for the new output matrix. Note high sensitivity of WFS2 YAW signal to PIT actuations. The worst row was for WFS2 YAW degree as expected (see page 3 attachment 3).

The new calculated output matrix (after product with the existing matrix) is:

                                                         YARM WFS Estimated Output Matrix

        WFS1 PIT         WFS2 PIT         WFS1 YAW         WFS2 YAW
     0.70+/-0.05    0.011+/-0.014   -0.203+/-0.032   -0.093+/-0.010  to ITMY PIT
    -0.42+/-0.04   -0.111+/-0.010    0.025+/-0.025    0.019+/-0.007  to ETMY PIT
    -0.00+/-0.05   -0.091+/-0.016      0.76+/-0.04    0.041+/-0.013  to ITMY YAW
   0.201+/-0.022    0.062+/-0.007    0.244+/-0.015    0.067+/-0.005  to ETMY YAW

With this matrix in, I had to change all gain signs to negative and teh loop was stable to my kick test on ITMY and ETMY on both PIT and YAW DOFs. OLTFs can be tuned further. Maybe later, I'll do another toggle testin hope of getting an identity matrix.

Attachment 1: YARM_WFS_OLTF.pdf
YARM_WFS_OLTF.pdf YARM_WFS_OLTF.pdf
Attachment 2: YARM_WFS_First_Attempt_1hr_history.pdf
YARM_WFS_First_Attempt_1hr_history.pdf
Attachment 3: YARM_WFS_DC_Sensing_Matrix_Step_Response_Test_1359774014.pdf
YARM_WFS_DC_Sensing_Matrix_Step_Response_Test_1359774014.pdf YARM_WFS_DC_Sensing_Matrix_Step_Response_Test_1359774014.pdf YARM_WFS_DC_Sensing_Matrix_Step_Response_Test_1359774014.pdf
ELOG V3.1.3-