40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 173 of 344 Not logged in
ID Date Author Type Category Subject
17111   Mon Aug 29 15:15:46 2022 TegaUpdateComputers3 FEs from LLO got delivered today

[JC, Tega]

We got the 3 front-ends from LLO today. The contents of each box are:

1. FE machine
2. OSS adapter card for connecting to I/O chassis
3. PCI riser cards (x2)
4. Timing Card and cable
5. Power cables, mounting brackets and accompanying screws
17113   Tue Aug 30 15:21:27 2022 TegaUpdateComputers3 FEs from LHO got delivered today

[Tega, JC]

We received the remaining 3 front-ends from LHO today. They each have a timing card and an OSS host adapter card installed. We also receive 3 dolphin DX cards. As with the previous packages from LLO, each box contains a rack mounting kit for the supermicro machine.

17144   Mon Sep 19 20:21:06 2022 TegaUpdateComputers1X7 and 1X6 work

[Tega, Paco, JC]

We moved the GPS network time server and the Frequency distribution amplifier from 1X7 to 1X6 and the PEM AA, ADC adapter and Martian network switch from 1X6 to 1X7. Also mounted the dolphin IX switch at the rear of 1X7 together with the DAQ and martian switches. This cleared up enough space to mount all the front-ends, however, we found that the mounting brackets for the frontends do not fit in the 1X7 rack, so I have decided to mount them on the upper part of the test stand for now while we come up with a fix for this problem. Attachments 1 to 3 show the current state of racks 1X6, 1X7 and the teststand.

Attachment 1: Front of racks 1X6 and 1X7

Attachment 2: Rear of rack 1X7

Attachment 3: Front of teststand rack

## Plan for the remainder of the week

Tuesday

• Setup the 6 new front-ends to boot off the FB1 clone.
• Test PCIe I/O cables by connecting them btw the front-ends and teststand I/O chassis one at a time to ensure they work
• Then lay the fiber cables to the various I/O chassis.

Wednesday

• Migrate the current models on the 6 front-ends to the new system.
• Replace RFM IPC parts with dolphin IPC parts in c1rfm model running c1sus machine
• Replace the RFM parts in c1iscex and c1iscey models
• Drop c1daf and c1oaf models from c1isc machine, since the front-ends have only have 6 cores
• Build and install models

Thursday [CAN I GET THE IFO ON THIS DAY PLEASE?]

• Complete any remaining model work
• Connect all I/O chassis to their respective (new) front-end and see if we can start the models (Need to think of a safe way to do this. Should we disconnect coil drivers b4 starting the models?)

Friday

• Tie-up any loose ends
17148   Tue Sep 20 23:06:23 2022 TegaUpdateComputersSetup the 6 new front-ends to boot off the FB1 clone

We wired the front-ends for power, DAQ and martian network connections. Then moved the I/O chassis from the buttom of the rack to the middle just above the KVM switch so we can leave the top og the I/O chassis open for access to the ports of OSS target adapter card for testing the extension fiber cables.

Attachment 1 (top -> bottom)

c1sus2

c1iscey

c1iscex

c1ioo

c1sus

c1lsc

When I turned on the test stand with the new front-ends, after a few minutes, the power to 1x7 was cut off due to overloading I assume. This brought down nodus, chiara and FB1. After Paco reset the tripped switch, everything came back without us actually doing anything, which is an interesting observation.

After this event, I moved the test stand power plug to the side wall rail socket. This seems fine so far. I then brought chiara (clone) and FB1 (clone) online. Here are some changes I made to get things going:

## Chiara (clone)

• Edited '/etc/dhcp/dhcpd.conf' to update the MAC address of the front-ends to match the new machines, then run
• sudo service isc-dhcp-server restart
• then restart front-ends
• Edited '/etc/hosts' on chiara to include c1iscex and c1iscey as these were missing

## FB1 (clone)

Getting the new front-ends booting off FB1 clone:

1. I found that the KVM screen was flooded with setup info about the dolphin cards on the LLO machines. This actually prevented login using the KVM switch for two of these machines.  Strangely, one of them 'c1sus' seemed to be fine, see attachment 2, so I guessed this was bcos the dolphin network was already configured earlier when we were testing the dolphin communications. So I decided to configure the remaining dolphin cards. To do so, we do the following

Dolphin Configuration:

1a. Ideally running

sudo /opt/DIS/sbin/dis_mkconf -fabrics 1 -sclw 8 -stt 1 -nodes c1lsc c1sus c1ioo c1iscex c1iscey c1sus2 -nosessions

should set up all the nodes, but this did not happen. In fact, I could no longer use the '/opt/DIS/sbin/dis_admin' GUI after running this operation and restarting the 'dis_networkmgr.service' via

sudo systemctl restart dis_networkmgr.service

so  I logged into each front-end and configured the dolphin adapter there using

sudo /opt/DIS/sbin/dis_config

After which I shut down FB1 (clone) bcos restarting it earlier didn't work, I waited a few minutes and then started it.  Everything was fine afterward, although I am not quite sure what solved the issue as I tried a few things and I was glad to see the problem go!

1b. I later found after configuring all the dolphin nodes that 2 of them failed the '/opt/DIS/sbin/dis_diag' test with an error message suggesting three possible issues of which one was 'faulty cable'. I looked at the units in question and found that swapping both cables with the remaining spares solved the problem. So it seems like these cables are faulty (need to double-check this). Attachment 3 shows the current state of the dolphin nodes on the front-ends and the dolphin switch.

2. I noticed that the NFS mount service for the mount points '/opt/rtcds' and '/opt/rtapps' in /etc/fstab exited with an error, so I ran

sudo mount -a

3. edit '/etc/hosts' to include c1iscex and c1iscey as these were missing

## Front-ends

To test the PCIe extension fiber cables that connect the front-ends to their respective I/O chassis, we run the following command (after booting the machine with the cable connected):

controls@c1lsc:~$lspci -vn | grep 10b5:3 Subsystem: 10b5:3120 Subsystem: 10b5:3101 If we see the output above, then both the cable and OSS card are fine (We know from previous tests that the OSS card on the I/O chassis is good). Since we only have one I/O chassis, we repeat the step above 8 times, also cycling through the six new front-end as we go so that we are also testing the installed OSS host adapter cards. I was able to test 4 cables and 4 OSS host cards (c1lsc, c1sus, c1ioo, c1sus2), but the remaining results were inconclusive (i.e. it seems to suggest that 3 out of the remaining 5 fiber cables are faulty, which in itself would be considered unfortunate but I found the reliability if the test to be in question when I went back to test the functionality to the 2 remaining OSS host cards using a cable that passed the test earlier and it didn't pass. After a few retries, I decided to call it a day b4 I lose my mind) and need to be redone again tomorrow. Note: We were unable to lay the cables today bcos these tests were not complete, so we are a bit behind the plan. Would see if we can catch up tomorrow. Quote: ## Plan for the remainder of the week Tuesday • Setup the 6 new front-ends to boot off the FB1 clone. • Test PCIe I/O cables by connecting them btw the front-ends and teststand I/O chassis one at a time to ensure they work • Then lay the fiber cables to the various I/O chassis. 17151 Wed Sep 21 17:16:14 2022 TegaUpdateComputersSetup the 6 new front-ends to boot off the FB1 clone [Tega, JC] We laid 4 out of 6 fiber cables today. The remaining 2 cables are for the I/O chassis on the vertex so we would test the cables the lay it tomorrow. We were also able to identify the problems with the 2 supposedly faulty cable, which are not faulty. One of them had a small bend in the connector that I was able to straighten out with a small plier and the other was a loose connection in the switch part. So there was no faulty cable, which is great! Chris wrote a matlab script that does the migration of all the model files. I am going through them, i.e. looking at the CDS parameter block to check that all is well. Next task is to build and install the updated models. Also need to update the '/opt/rtcds' and '/opt/rtapps' directory to the latest in the 40m chiara system. 17153 Thu Sep 22 20:57:16 2022 TegaUpdateComputersbuild, install and start 40m models on teststand [Tega, Chris] We built, installed and started all the 40m models on the teststand today. The configuration we employ is to connect c1sus to the teststand I/O chassis and use dolphin to send the timing to other frontends. To get this far, we encounterd a few problems that was solved by doing the following: 0. Fixed frontend timing sync to FB1 via ntp 1. Set the rtcds enviroment variable CDS_SRC=/opt/rtcds/userapps/trunk/cds/common/src in the file '/etc/advligorts/env' 2. Resolved chgrp error during models installation using sticky bits on chiara, i.e. sudo chmod g+s -R /opt/rtcds/caltech/c1/target 3. Replaced sqrt with lsqrt in RMSeval.c to eliminate compilation error for c1ioo 4. Created a symlink for 'activateDQ.py' and 'generate_KisselButton.py' in '/opt/rtcds/caltech/c1/post_build' 5. Installed and configured dolphin for new frontend 'c1shimmer' 6. Replaced 'RFM0' with 'PCIE' in the ipc file, '/opt/rtcds/caltech/c1/chans/ipc/C1.ipc' We still have a few issues namely: 1. The user models are not running smoothly. the cpu usage jumps to its maximum value every second or so. 2. c1omc seems to be unable to get its timing from its IOP model (Issue resolved by changing the CDS block parameter 'specific_cpu' from 6 to 4 bcos the new FEs only have 6 cores, 0-5) 3. The need to load the dolphin-proxy-km library and start the rts-dolphin_daemon service whenever we reboot the front-end 17158 Fri Sep 23 19:07:03 2022 TegaUpdateComputersWork to improve stability of 40m models running on teststand [Chris, Tega] ## Timing glitch investigation: • Moved dolphin transmit node from c1sus to c1lsc bcos we suspect that the glitch might be coming from the c1sus machine (earlier c1pem on c1sus was running faster then realtime). • Installed and started c1oaf to remove the shared memory IPC error to/from c1lsc model • /opt/DIS/sbin/dis_diag gives two warnings on c1sus2 • [WARN] IXH Adapter 0 - PCIe slot link speed is only Gen1 • [WARN] Node 28 not reachable, but is an entry in the dishosts.conf file - c1shimmer is currently off, so this is fine. ## DAQ network setup: • Added the DAQ ethernet MAC address and fixed IPV4 address for the front-ends to '/etc/dhcp/dhcpd.conf' • Added the fixed DAQ IPV4 address and port for all the front-ends to '/etc/advligorts/subscriptions.txt' for cps_recv service • Edited '/etc/advligorts/master' by including all the iop and user models '.ini' files in '/opt/rtcds/caltech/c1/chans/daq/' containing channel info and the corresponding tespoint files in '/opt/rtcds/caltech/c1/target/gds/param/' • Created systemd environment file for each front-end in '/diskless/root/etc/advligorts/' containing the argument for local data concentrator and daq data transmitter (local_dc_args and cps_xmit_args). We currently have staggered the delay (-D waitValue) times of the front-ends by setting it to the last number in the daq ip address when we were facing timing glitch issues, but should probably set it back to zero to see if it has any effect. ## Other: • Edited /etc/resolv.conf on fb1 and 'diskless/root' to enable name resolution via for example host c1shimmer but the file gets overwritten on chiara for some reason ## Issues: 1. Frame writing is not working at the moment. It did at some point in the past for a couple of days but stopped working earlier today and we can't quite figure out why. 2. We can't get data via diaggui or ndscope either. Again, we recall the working in the past too but not sure why it has stopped working now. 3. The cpu load on c1su2 is too high so we should split into two models 4. We still get the occassional IPC glitch both for shared memory and dolphin, see attachments 17169 Mon Oct 3 08:35:59 2022 TegaUpdateIMCAdding IMC channels to frames for NN test [Rana] For the upcoming NN test on the IMC, we need to add some more channels to the frames. Can someone please add the MC2 TRANS SUM, PIT, YAW at 256 Hz? and then make sure they're in frames. and even though its not working correctly, it would be good if someone can turn the MC WFS on for a little while. I'd just like to get some data to test some code. If its easy to roughly close the loops, that would be helpful too. [Anchal] Currently, none of these channels are being written on frames. From simulink model, it seems the channels: • C1:IOO-MC_TRANS_SUMFILT_OUT_DQ • C1:IOO-MC_TRANS_PIT_OUT_DQ • C1:IOO-MC_TRANS_YAW_OUT_DQ are supposed to be DQed but are not present in the /opt/rtcds/caltech/c1/chans/daq/C1MCS.ini file. I tried simply adding these channels to the file and rerunning the daqd_ services but that caused 0x2000 error on c1mcs model. In my attempt, I did not know what chnnum to give for these channels so I omitted that and maybe that is the issue. The only way I know to fix this is to make and install c1mcs model again which would bring these channels into C1MCS.ini file. But We'll have to run activateDQ.py if we do that which I am not totally sure if it is in running condition right now. @Christopher Wipf do you have any suggestions? [Rana] aren't they all filtered? If so, perhaps we can choose whatever is the equivalent naming at the LIGO sites rather than roll our own again. @Tega Edo can we run activateDQ.py or will that break everything now? [Tega] @Rana Adhikari Looking into this now. @Anchal Gupta The only problem I see with activateDQ.py is the use of the deprecated print function, i.e. print var instead of print(var). After fixing that, it runs OK and does not change the input INI files as they already have the required channel names. I have created a temporary folder, /opt/rtcds/caltech/c1/chans/daq/activateDQtests/, which is populated with copies of the original INI files, a modified version of activateDQ.py that does not overwrite the original input files, and a script file difftest.sh that compares the input and output files so we can test the functionality of activateDQ.py in isolation. Furthermore, looking through the code suggests that all is well. Can you look at what I have done to check that this is indeed the case? If so, your suggestion of rebuilding and installing the updated c1mcs model and running activateDQ.py afterward should do the trick. I tested the code with: cd /opt/rtcds/caltech/c1/chans/daq/activateDQtests/ ./activateDQ.py which creates output files with an _ prefix, for example _C1MCS.ini is the output file for C1MCS.ini, then I ran ./difftest to compare all the input and corresponding output files. Note that the channel names you are proposing would change after running activateDQ.py, i.e. C1:IOO-MC_TRANS_SUMFILT_OUT_DQ -> C1:IOO-MC_TRANS_SUM_ERR C1:IOO-MC_TRANS_PIT_OUT_DQ -> C1:IOO-MC_TRANS_PIT_ERR C1:IOO-MC_TRANS_YAW_OUT_DQ -> C1:IOO-MC_TRANS_YAW_ERR My question is this: why aren't we using the correct channel names in the first place so that we have less work to do later on when we finally decide to stop using this postbuild script? [Anchal] Yeah I found that these ERR channels are acquired and stored. I don't think we should do this either. Not sure what was the original motivation for this change. I tried commenting out this part of activateDQ.py and remaking and reinstalled c1mcs but it seems that activateDQ.py is called as postbuild script automatically on install and it uses some other copy of this file as my changes did not take affect and the DQ name change still happened. [Tega] Ah, we encountered the same puzzle as well. Chris found out that our models have SCRIPT=activateDQ.py embedded in the cds parameter block description, see attached image. We believe this is what triggers the postbuild script call to activateDQ.py. As for the file location, modern rtcds would have it in /opt/rtcds/caltech/c1/post_build, but I am not sure where ours is located. I did a quick search for this but could not find it in the usual place so I looked around for a bit and found this: controls@rossa> find /opt/rtcds/userapps/ -name "activateDQ.py" /opt/rtcds/userapps/trunk.bak/cds/c1/scripts/activateDQ.py /opt/rtcds/userapps/tags/H2OAT_RCG2.5.1/cds/c1/scripts/activateDQ.py /opt/rtcds/userapps/branches/StanfordGuardianDev/cds/c1/scripts/activateDQ.py /opt/rtcds/userapps/branches/branch-2.3/cds/c1/scripts/activateDQ.py /opt/rtcds/userapps/branches/branch-2.4/cds/c1/scripts/activateDQ.py /opt/rtcds/userapps/trunk/cds/c1/scripts/activateDQ.py My guess is the last one /opt/rtcds/userapps/trunk/cds/c1/scripts/activateDQ.py. Maybe we can ask @Yuta Michimura since he wrote this script? Anyway, we could also try removing SCRIPT=activateDQ.py from the cds parameter block description to see if that stops the postbuild script call, but keep in mind that doing so would also stop the update of the OSEM and oplev channel names. This way we know what script is being used since we will have to run it after every install (this is a bad idea). controls@c1sus:~ 0$ env | grep script

CDS_SCRIPTS_PATH=:/opt/rtcds/userapps/release/cds/c1/scripts:/opt/rtcds/userapps/release/cds/common/scripts:/opt/rtcds/userapps/release/isc/c1/scripts:/opt/rtcds/userapps/release/isc/common/scripts:/opt/rtcds/userapps/release/sus/c1/scripts:/opt/rtcds/userapps/release/sus/common/scripts

It looks like the guess was correct. Note that in the newer version of rtcds, we can use rtcds env instead of env to see what is going on.

17197   Tue Oct 18 15:24:48 2022 TegaUpdateCDSRack 1X7 work proposal

We have decided to split the remaining CDS work on rack 1x7 into two phases, both of which end with us bringing the 40m systems back up.

Phase 1 (Clear rack 1X7 of all mounted pieces of equipment)

• Move nodus to 1X6 bottom slot
• Move optimus to 1X6 (replaces old fat FB which can be moved to storage)
• Move DAQ and network switches to the top of 1X7 rack
• Move the UPS to under 1X6
• Clear 1X7 power rail of any connections

Phase 2 (Replace the mounting rails and mount all pieces of equipment)

• Mount DAQ, network and Dolphin switches at the top rear of 1x7 rack
• Mount 6 new front-ends
• Mount KVM switch
• Move nodus back to 1X7
• Move optimus back to 1X7

17202   Thu Oct 20 19:47:24 2022 TegaUpdateCDSRelocate front-ends to Rack 1X7

We mounted chiara, all front-end machines and switches in rack 1x7; reconnected power, dolphin, onestop and timing cables; and restarted the front-ends. Attachments 1 & 2 show the front and rear of rack 1X7. We are going to continue the clean up work tomorrow.

The ifo is not back up as can be seen in attachment 3. We think the timing issue mentioned earlier is the culprit, but all FEs seem to agree to within a second, so I am not sure. I restarted the models with iop errors other than the timing error, i.e. c1lsc, c1sus, c1ioo and c1iscex. This eliminated most of the errors but the timing error. However, the overflow field on c1lsc is non-zero and the number keeps increasing - indicating a problem with c1lsc? The new status is shown in attachement 4. My understanfin is the a red TIM flag in the CDS stateword is not a functional problem, so I guess we are almost there. I did a burt restore on rossa using a snapshot we took earlier today before the shutdown, reset the SUS watchdogs and started the docker services on optimus. Now the IMC is locked.

We are still getting shared memory glitch on c1ioo, see attachment 5.

Note: We left nodus, megatron, optimus and fb1 in rack 1X6 for now.

17250   Wed Nov 9 14:19:18 2022 TegaUpdateCDSfb1 OS migration

[Tega, Chris]

We migrated fb1 OS from the teststand fb1 drive to the internal 2TB RAID of fb1. We then rebooted twice to check that we no longer have the fb1 booting issue.

The next step is to set up software RAID and backup for chiara, which we plan to complete this week. Then we would work on nodus and workstation OS upgrade next week.

17293   Mon Nov 21 15:16:12 2022 TegaUpdateCDSworkstation upgrade

We are currently working on donatella workstation upgrade, which we are calling donatellaclone for now. After installing Debian 11, we install the cds conda environment. This takes care of most of the requisite packages except dataviewer and burtgooey.

To resolve the machines on the martian network, we do the following:

sudo apt update

sudo apt install resolvconf

then create or open the file '/etc/resolvconf/resolv.conf.d/head'

sudo nano /etc/resolvconf/resolv.conf.d/head

and add the following

nameserver 192.168.113.104

nameserver 8.8.8.8

search martian

burtgooey:

The installation binary for burtgooey /usr/bin/burtgooey is a symoblic link that points to /ligo/apps/epics-3.14.10/extensions/bin/linux-x86_64/burtgooey. To get this working, we need to install some requisite libraries, see below:

sudo apt-get install libxm4

wget -c http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/multiarch-support_2.27-3ubuntu1_amd64.deb

sudo dpkg -i multiarch-support_2.27-3ubuntu1_amd64.deb

wget -c http://ftp.debian.org/debian/pool/main/g/glibc/multiarch-support_2.28-10+deb10u1_amd64.deb

sudo dpkg -i multiarch-support_2.28-10+deb10u1_amd64.deb

wget -c https://apt.ligo-wa.caltech.edu:8443/debian/pool/bullseye/libxp6/libxp6_1.0.2-2_amd64.deb

sudo dpkg -i libxp6_1.0.2-2_amd64.deb

wget -c http://ftp.debian.org/debian/pool/main/r/readline6/libreadline6_6.3-8+b3_amd64.deb

sudo apt-get install -y libtinfo5

sudo dpkg -i libreadline6_6.3-8+b3_amd64.deb

sudo add-apt-repository universe

sudo apt-get install libncurses5

dataviewer:

dataviewer depends on 'grace' and 'libmotif-dev' which are not installed automatically and results in a broken initial installation, so do the following:

sudo apt-get install dataviewer

sudo apt --fix-broken install

17299   Tue Nov 22 15:33:02 2022 TegaUpdateCDSI/O chassis parts inventory

[Tega, JC]

We received the following I/O chassis parts from LLO:

 Components Quantity Timing Master 1 I/O chassis timing interface 8 I/O chassis backplane board 18 I/O chassis motherboard 20 M4 power supply 36

17304   Wed Nov 23 16:12:00 2022 TegaUpdateCDSI/O chassis parts inventory II

[Tega, JC]

We picked up the following I/O chassis components from Downs CDS testing lab:

 Components Quantity I/O chassis timing interface (missing aLIGO Duotone to IO interface adapter board) 1 Digital I/O PCI Express card 16ch/16ch 1 Adnaco PCI Express Gen 2 Extension System 1 PCIe x4 host interface board 6 OSS expansion Link board x4 1 OSS expansion Link board x4/x8 Gen2 3 aLIGO 16-Bit DAC Adapter board 1 aLIGO 18-Bit DAC Adapter board 12 GSC PMC-PCI adapter board 11 GSC PCIe-PMC adapter board 2 Avago LC transceiver (HFBR-57E0PZ) 9
12489   Tue Sep 13 19:02:56 2016 TengUpdateGeneralITMX sensor

[Lydia,Teng]

Something strange happened to the ITMX osem reading around 4.pm. PDT as shown below.

Also the there was no response of the reading as we adjusted the PITCH and YAW. :(

Note that we restarted the slow machine: c1susaux,c1ausex this afternoon because of the unresponced interface.

12505   Mon Sep 19 13:25:03 2016 TengUpdateElectronicsSatellite Amplifier

In order to figure out the difference betweent simulated result and measurement, I tried to measuren the electronic noise by following ways as show in attachment 1

1.measure from the satellite box by SR785 at ETMY ,calibrate to counts by divide by 3267.8. while at that conditin, the set up is in suspension.

2. measure after ADC by diagnostics test tools, with set up on table in history and on uspension currently.

3. use the caculated butterfly channel.

the results are shown in attachmemt 2. The overall nosie level are still much higher than simulation.

Quote:

 If we have some data with one of the optics clamped and the open light hitting the PD, or with the OSEMs removed and sitting on the table, that would be useful for evaluating the end-to-end noise of the OSEM circuit. It seems like we probably have that due to the vent work, so please post the times here if you have them.

The ETMX OSEMs have been attached to its Satellite box and plugged in for the last 10 days or so, with the PD exposed to the unobstructed LED. I pulled the spectrum of one of the sensors (mean detrended, I assume this takes care of removing the DC value?). The DQed channels claim to record um (the raw ADC counts are multiplied by a conversion factor of 0.36). For comparison, re-converted the y-axis for the measured curve to counts, and multiplied the total noise curve from the LISO simulation by a factor of 3267.8cts/V (2^16cts/20V) so the Y axis is noise in units of counts/rtHz. At 1Hz, there is more than an order of magnitude difference between the simulation and the measurement which makes me suspect my y-axis conversion, but I think I've done this correctly. Can such a large discrepancy be solely due to thick film resistors?

18   Fri Oct 26 16:19:29 2007 Tobin FrickeRoutineIOOMC resonances
We would like to measure the absorption of the mode cleaner optics. The plan is to repeat <a href="http://ilog.ligo-wa.caltech.edu:7285/mLIGO/Cleaning_the_Mode_Cleaner">Valera's experiment</a> in which we track the MC's thermal resonances to infer their power absorption. Last night Rana and I hooked up a lock-in amplifier to heterodyne the MC servo signal by 28 kHz and piped the output into an ADC using the MC_AO channel. We did not find any resonances.

Valera recommends we drive the POS of the three MC optics with bandlimited noise to excite the resonances.
16930   Mon Jun 20 19:46:04 2022 TomislavUpdateASCSimulation plots

In the attachment please find IMC ASC simulation plots. Let me know what you think, if you want some other plots, and if you need any clarification.

16934   Tue Jun 21 18:41:46 2022 TomislavUpdateASCSimulation plot

In the attachment please find a comparison of error signals of simulation and reality. For C1:IOO-WFS1/2_PIT_IN1 excess signal ('belly') between a few Hz up to 70-80 Hz might be caused by air turbulence (which is not included in the simulation).

16937   Tue Jun 21 22:22:37 2022 TomislavUpdateASCPlots

In the attachment please find a comparison of error signals of simulation and reality after including air turbulence as input noise.

16948   Sat Jun 25 22:18:41 2022 TomislavUpdateASCSimulation and reality comparisons

In the attachment please find plots comparing controller output, local damping output, and error signals.

Input noises of the simulation are seismic noise, osem noise, input power fluctuations, sensing noises of WFSs and QPD, and air turbulence noise for WFSs. There is also optical torque noise (radiation pressure effect).

The procedure to get optical gains and sensing noises:
Having the actuator response A rad/cnts @ 3 Hz. I was shaking MC1/2/3 in pitch with B cnts @ 3 Hz and getting WFS1/2 QPD signals of C cnts @ 3 Hz, which means WFS1/2 QPD optical gain is D cnts/rad = C / (A * B) cnts/rad. So, if WFS1/2 QPD IN1 has a noise spectrum (at higher freqs) of E cnts/rtHz, that corresponds to E/D rad/rtHz of sensing noise for WFS1/2 QPD.

Actuator response [rad/cts] I was getting shaking mirrors at 3 Hz and measuring amplitudes of OSEM output (knowing the geometry of the mirror). I scaled it to DC. From here I was getting ct2tau_mc (knowing the mirror's moment of inertia, Q, and natural pitch frequencies). OSEM calibration factors [cts/rad] I was getting from the input matrix and geometry of the mirror.

The flat noise at higher frequencies from the local damping and controller output channels is presumably quantization/loss of digits/numerical precision noise which I don't include in simulations for now?!

Regarding air turbulence, in KAGRA it has been reported that air turbulence introduces phase fluctuations in laser fields that propagate in air. According to Kolmogorov’s theory, the PSD of phase fluctuations caused by air turbulence scales as ∝ L*V^(5/3)*f^(−8/3). Here, L is the optical path length and V is a constant wind speed. Since it is not obvious how can one estimate typical V in the beam paths I was taking this excess noise from the error signals data between 10 Hz and 50 Hz, extrapolated it taking into account ∝ f^(−8/3) (not for frequencies below 2 Hz, where I just put constant, since it would go too high). I expect that I won't be able to get a parameterized model that also predicts the absolute value. The slope is all I can hope to match, and this I already know. QPD chamber is much smaller (and better isolated?) and there is no this excess noise.

Regarding other things in simulations (very briefly): beam-spots are calculated from angular motions, length change is calculated from beam-spots and angular motion, cavity power depends on length change and input power, and torque on the mirrors depends on beam-spots and cavity power. From other things, local-sensor basis conversion (and vice versa) is worth noting.

16958   Tue Jun 28 18:19:09 2022 TomislavUpdateElectronicsElectronics noise

I measured electronics noise of WFSs and QPD (of the WFS/QPD, whitening, ADC...) by closing PSL and measuring the error signal. It was needed to put the offset in C1:IOO-MC_TRANS_SUMFILT_OFFSET to 14000 cts (without offset the sum of quadrants would give zero, and 14000 cts is the value when the cavity is locked). For WFS that are RF, if there is intensity noise at low frequencies, it is not affecting the measurement.

In the attachment please find the power spectrum of the error signal when the PSL shutter is on and off.

16972   Tue Jul 5 20:05:06 2022 TomislavUpdateElectronicsWhitening electronics noise

For whitening electronics noise for WFS1, I get (attachment). This doesn't seem right, right?

16992   Tue Jul 12 14:56:17 2022 TomislavSummaryElectronicsElectronics noise measurements

[Paco, Tomislav]

We measured the electronics noise of the demodulation board, whitening board, and ADC for WFSs, and OPLEV board and ADC for DC QPD in MC2 transmission. We were using SR785.

Regarding the demodulation board, we did 2 series of measurements. For the first series of measurements, we were blocking WFS (attachment 1) and measuring noise at the output of the demod board (attachment 2a). This measurement includes dark noise of the WFS, electronics noise of demod board, and phase noise from LO. For the second series of the measurements, we were unplugging input to the demod board (attachment 2b & 2c is how they looked like before unplugging) (the mistake we made here is not putting 50-ohm terminator) and again measuring at the output of the demod board. This measurement doesn't include the dark noise of the WFS. We were measuring it for all 8 segments (I1, I2, I3, I4, Q1, Q2, Q3, Q4). The dark noise contribution is negligible with respect to demod board noise. In attachments 3 & 4 please find plots that include detection and demodulation contributions for both WFSs.

For whitening board electronics noise measurement, we were terminating the inputs (attachment 5) and measuring the outputs (attachment 6). Electronics noise of the whitening board is in the attachments 7 & 8.

For ADC electronics noise we terminated ADC input and measured noise using diaggui (attachments 9 & 10). Please find these spectra for WFS1, WFS2, and MC TRANS in attachments 11, 12 & 13.

For MC2 TRANS we measured OPLEV board noise. We did two sets of measurements, as for demod board of WFSs (with and without QPD dark noise) (attachments 14, 15 & 16). In the case of OPLEV board noise without dark noise, we were terminating the OPLEV input. Please find the electronics noise of OPLEV's segment 1 (including dark noise which is again much smaller with respect to the OPLEV's electronics noise) in attachment 17.

For the transfer functions, demod board has flat tf, whitening board tf please find in attachment 18, ADC tf is flat and it is (2**16 - 1)/20 [cts/V], and dewhitening tf please find in attachment 19. Also please find the ASD of the spectral analyzer noise (attachment_20).

Measurements for WFS1 demod and whitening were done on 5th of July between 15h and 18h local time. Measurements for WFS2 demod and whitening were done on 6th of July between 15h and 17h local time. All the rest were done on July 7th between 14h and 19h. In attachment 21 also find the comparison between electronics noise for WFSs and cds error signal (taken on the 28th of June between 17h and 18h). Sorry for bad quality of some pictures.

16763   Thu Apr 7 20:33:42 2022 TommyUpdateElectronicsRFSoC 2x2 board -- setup for remote work

To access the board remotely through the 40m lab ethernet port, use

ssh -N -L localhost:1137:localhost:9090 xilinx@<ip_address>

Then in the browser go to

localhost:1137/lab

Other SSH commands using different ports or without the -N -L seemed to fail to open Jupyter. This way has been successful thereafter.

 Quote: [Tommy, Paco] Since last week I've worked with tommy on getting the RFSoC 2x2 board to get some TFs from simple minicircuits type filters. The first thing I did was set up the board (which is in the office area) for remote access. I hooked up the TCP/IP port to a wall ethernet socket (LIGO-04) and the caltech network assiggned some IP address to our box. I guess eventually we can put this behind the lab network for internal use only. After fiddling around with the tone-generators and spectrum analyzer tools in loopback configuration (DAC --> ADC direct connection), we noticed that lower frequency (~ 1 MHz) signals were hardly making it out/back into the board... so we looked at some of the schematics found here and saw that both RF data converters (ADC & DAC) interfaces are AC coupled through a BALUN network in the 10 - 8000 MHz band (see Attachment #1). This is in principle not great news if we want to get this board ready for audio-band DSP. We decided that while Tommy works on measuring TFs for SHP-200 all the way up to ~ 2 GHz (which is possible with the board as is) I will design and put together an analog modulation/demodulation frontend so we can upconvert all our "slow" signals < 1MHz for fast, wideband DSP. and demodulate them back into the audio band. The BALUN network is pictured in Attachment #2 on the board, I'm afraid it's not very simple to bypass without damaging the PCB or causing some other unwanted effect on the high-speed DSP.

16764   Thu Apr 7 20:37:06 2022 TommyUpdateElectronicsRFSoC 2x2 Board -- Simple Tone Generator

In the "Tommy" sub folder, I created a new notebook called "SimpleToneGenerator". This tunes the DAC and ADC mixers to a single frequency and reads off the Time Series and Fourier components. We can alos easily check the demodulation scheme and implement butterworth filters to check their function.

16765   Thu Apr 7 20:41:15 2022 TommyUpdateElectronicsRFSoC 2x2 Board -- Gain Plotter

In this file (under Tommy), we have a notebook which runs through a spectrum of frequencies and determines the gain response of the attached filter. Below we have the output of a high pass filter. We use IQ demodulation to change IQ componets to DC. Then using a butterworth filter, we read out the DC components and determine the gain's magnitude and phase. However, the phase seems very noisy. This is because the oscillators in the different tiles are independent and a random phase is introduced by changing the mixer frequency in individual tiles. To resolve this we need Multi Tile Synchronization or "MTS".

Original Pynq Support Forum Query: https://discuss.pynq.io/t/rfsoc-2x2-phase-measurement/3892

We also have the code to fit a resposne function using IIRregular, but this is not as useful without proper phase data.

16790   Wed Apr 20 14:56:06 2022 TommyUpdateElectronicsRFSoC 2x2 board -- setup for remote work & BALUN saga

Here are a few options for replacement BALUNs from Mini Circuits and specs:

Current. TCM1-83X+, 10-8000 MHz, 50 Ohms, Impedance Ratio 1, Configuration K

1. Z7550-..., DC-2500 MHz (some DC-2300), 50/75 Ohms, Impedance Ratio 1.5, Configuration Q. There are various types of the Z7550 which have different connectors (SMA and BNCs). These have much larger dimensions than the TCM1-83X. Can handle up to 5A DC current with matching loss 0.6 dB.

2. SFMP-5075+, DC-2500 MHz, 50/75 Ohms, Impedance Ratio 1.5, Configuration D. This is an SMA connected BALUN. It can handle 350mA, has a matching loss 0.4 dB, and has 1W power handling.

Quote:

Seems like it should be possible to just remove the transformer (aka as a BALUN ... BALanced, UNbalanced), or replace it with a lower frequency part. Its just a usual mini-circuits part. Maybe you can ask Chris Stoughton about this and ask Tommy to checkout some of the RFSoC user forums for how to go to DC.

 Quote: After fiddling around with the tone-generators and spectrum analyzer tools in loopback configuration (DAC --> ADC direct connection), we noticed that lower frequency (~ 1 MHz) signals were hardly making it out/back into the board... so we looked at some of the schematics found here and saw that both RF data converters (ADC & DAC) interfaces are AC coupled through a BALUN network in the 10 - 8000 MHz band (see Attachment #1). This is in principle not great news if we want to get this board ready for audio-band DSP. We decided that while Tommy works on measuring TFs for SHP-200 all the way up to ~ 2 GHz (which is possible with the board as is) I will design and put together an analog modulation/demodulation frontend so we can upconvert all our "slow" signals < 1MHz for fast, wideband DSP. and demodulate them back into the audio band. The BALUN network is pictured in Attachment #2 on the board, I'm afraid it's not very simple to bypass without damaging the PCB or causing some other unwanted effect on the high-speed DSP.

 model_no case_style single2single single2bal bal2bal center_tap dc_iso freq_low freq_high impedance imped_ratio interface tech config SFMP-5075+ FF1891 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE D TCM1-83X+ DB1627 N Y Y N N 10 8000 50 1 SMT CORE & WIRE K Z7550-BFNF+ H795-14 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE Q Z7550-BMBF+ QP1876-1 Y N N N N DC 2300 50/75 1.5 CON CORE & WIRE D1 Z7550-BMNF+ QP1876 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE Q Z7550-FFNM+ H795-1 Y N N N N DC 2300 50/75 1.5 CON CORE & WIRE Q Z7550-FFSF+ H557-1 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE Q Z7550-FMSF+ H795-3 Y N N N N DC 2300 50/75 1.5 CON CORE & WIRE Q Z7550-FMSFDC+ H795-3 Y N N N Y 1 2500 50/75 1.5 CON CORE & WIRE Q Z7550-NFNF+ H795-10 Y N N N N DC 2500 50/75 1.5 CON CORE & WIRE D1 Z7550-NMNF+ H795-4 Y N N N N DC 2300 50/75 1.5 CON CORE & WIRE Q
16807   Sun Apr 24 13:17:08 2022 TommyUpdateElectronicsNew RFSoC2x2 Overlay

We recieved an overlay from Chris Stoughton which he used for a ZCU11 board. The overlay is supposed to be compatible with the RFSoC 2x2 and help enable the Multi-Tile Synchronization (MTS) we need. He also provides a .py with the necessary low level connection to the board and its memory along with a few sample notebooks.

Progress So Far:

• The overlay loads properly and in reasonable time.
• We can set the mixer and dac frequencies. However, it is unclear what event_src Chris wanted for the adc mixers. It seems that he was using event_src_immediate (possibly unintenionally) which is not an available adc mixer setting in our board. Instead, we set the event source to "Tile" and will later determine if this is an issue.
• We then go to get data from the buffer. There are two functions called: capture and transfer. These are called on the pynq DMA. Capture runs fine but we get stuck during the transfer at dma.revchannel.wait(). This issue has not been resolved.
16813   Tue Apr 26 16:23:22 2022 TommyUpdateElectronicsRFSoC2x2 MTS

We connected a 8 MHz signal generator to the device in order to sync up the ADCs and DACs and hopefully get phase data.

Some things to note:

• RF Manual (143)- Need to use XRFDC SYSREF for update event
• RF Manual (171)- Synchronization steps require us to first enable all clocks and sysref generators (via xrfdc package)
• RF Manual (173)- Sysref requirments, not clear if PL is syncing as needed.
• RF Manual (181)- XRFDC example code, see also https://github.com/Xilinx/embeddedsw/blob/master/XilinxProcessorIPLib/drivers/rfdc/examples/xrfdc_mts_example.c

Xilinx RF Manual: https://docs.xilinx.com/v/u/2.4-English/pg269-rf-data-converter

16857   Mon May 16 14:46:35 2022 TommyUpdateElectronicsRFSoC MTS Work

We followed the manual's guide for setting up MTS to sync on external signal. In the xrfdc package, we update the RFdc class to have RunMTS, SysRefEnable, and SysRefDisable functions as prescribed on page 180 of the manual. Then, we attempted to run the new functions in the notebook and read the DAC signal outputs on an oscilloscope. The DACs were not synced. We were also unable to get FIFOlatency readings.

16876   Thu May 26 15:55:10 2022 TommyUpdateElectronicsRFSoC Power Spectrum

Finished building power spectrum analyzer for the RFSoC. There are two things that I would like to address down the road. First is that there is an oscillation between positive and negative voltages at the ADC sampling frequency. This creates an undesirable frequency component at the sampling rate. I have not yet figured out the cause of this positive to negative oscillation and have simply removed half of the samples in order to recover the frequency. Therefore, I would like to figure out the root of this oscillation and remove it. Also, we have a decimation factor of 2 as default by the board which we would like to remove but have been unable to do so.

Example: 8 MHz Square Wave from SRL signal generator.

16879   Fri May 27 15:53:17 2022 TommyUpdateElectronicsRFSoC MTS Work

With some help from the forums, we printed the status of the DAC MTS sync and were able to determined that our board's vivado design does not have MTS enabled on each tile. To fix this, we will need to construct a new Vivado desgin for the board. We were also warned to "make sure to generate correctly a PL_clock and a PL_sysref with your on board clock synthesizers and to capture them in the logic according to the requirements in PG269" of the RF Manual. From this we should be able to sync the DAC and ADC tiles as desired.

 Quote: We followed the manual's guide for setting up MTS to sync on external signal. In the xrfdc package, we update the RFdc class to have RunMTS, SysRefEnable, and SysRefDisable functions as prescribed on page 180 of the manual. Then, we attempted to run the new functions in the notebook and read the DAC signal outputs on an oscilloscope. The DACs were not synced. We were also unable to get FIFOlatency readings.

14014   Mon Jun 25 19:14:02 2018 UditSummaryGeneralRe: A summary of the Tip-TIlt Mirror Holder design changes

2. Weighted screw rod at the bottom for tilting the mirror-holder:

The screw length selected here (2") is not interfering with any part of the assembly.

The 'weights' I have here are just thumb nuts from Mcmaster, so their weight is fixed (1.65g each, btw).

Problem I'd like to solve: Find an assortment of weighted, symmetric nuts with caps on one end to fix position on shaft.

3. Set-screws on both side of wire clamp to adjust its horizontal position:

Thanks for pointing out the mismatch in travel distance of protrusion and clamp screws. To match them, the clamp screw slot now sticks out of the profile (by 1.5mm). The range of the clamp motion is +/- 3 mm.

Also, here's a screenshot of the slot in the mirror holder:

--

- Excluding the weighted screw rod assembly, the height gap between assembly COM and wire release point is 3.1 mm.

 Quote: > 2. Weighted screw rod at the bottom for tilting the mirror-holder: Too long. The design of the holder should be check with the entire assembly. We should be able to make it compact if we heavier weights. How are these weights fixed on the shaft? Also can we have options for smaller weights for the case we don't need such a range? Note the mass of the weights. > 3. Set-screws on both side of wire clamp to adjust its horizontal position: How much is the range of the clamp motion limited by the slot for the side screws and the slot for the protrusion? Are they matched? Can you show us the design of the slot made on the mirror holder? >> Where is the center of mass (CoM) for the entire mirror holder assy and how much is the height gap between the CoM and the wire release points. Can you do this with 3/8" and 1/2" fused silica mirrors?

13429   Thu Nov 16 00:14:47 2017 Udit KhandelwalUpdateSUSSOS Sapphire Prism design

Summary:

• SOS solidworks model is nearly complete
• Having trouble with the design of the sensor/actuator head assembly and the lower clamps
• After Gautam's suggestion, installed Abaqus on computer. Teaching it to myself to eventually do FEM analysis and find resonant frequency of the system
• Goal is to replicate frequency listed in the SOS documents to confirm accuracy of computer model, then replace guide rods with sapphire prisms and change geometry to get same results

Questions:

• How accurate do the details (like fillet, chamfer, placement of little vent holes), and material of the different SOS parts need to be in the model?
• If I could get pictures of the lower mirror clamp (document D960008), it would be helpful in making solidworks model. Document is unclear. Same for sensor/actuator head assembly.
13460   Fri Dec 1 17:09:29 2017 Udit KhandelwalSummaryGeneral

Current objectives and statuses:

• CAD Model of 40m lab (facility, chambers, invacuum components etc)
• Status: On hold since I'm unable to acquire general dimensions of
13472   Wed Dec 13 17:46:08 2017 Udit KhandelwalSummaryGeneralSummary of Current Tasks

1. 40m_bldg.dwg has 2D drawing of the 40m building

• After importing file as a 2D sketch into solidworks, make sure to retrace all the lines before performing any 3D extrusion stuff.
• Made walls 3m high

2. 40m_VE.dwg has the Vaccuum Envelope.

• Divided the file into individual sketches for the tubes, test mass, and beam splitter chambers (so they can be individually modified later if required).

3. 40melev.dwg has the relative positioning between (1) and (2).

• Using this file to position objects inside building cad.

4. All files can be found in Dropbox folder [40m SOS Modeling], which should be renamed to [40m CAD].

5. Next step would be to add the optical table, mirrors.

Tip-Tilt Suspension

1. Current objective: (refer to D070172) - Increase the length of the side arms (so it matches the dimensions of D960001), while keeping the test mass subassembly at the same height.
2. Future objective: Resonant frequency FEM of the frame (sans the test mass), and then change height to get the desired frequency.

Past Work

• Completed solidworks model of SOS (D960001). I understand this is not the focus right now so this is for reference that the model is ready to be used.

• I will be in India from 16th December until 6th January so this is my final visit for this year. I have enough material to work from home, and will correspond with Koji over email regarding Lab CAD and tip-tilt suspension.
13544   Fri Jan 12 20:35:34 2018 Udit KhandelwalSummaryGeneral2018/01/12 Summary
1. 40m Lab CAD
1. Worked further on positioning vacuum tubes and chambers in the building.
2. Next step would be to find some drawings for optical table positions and vibration isolation stack. Need help with this!
2. Tip Tilt Suspension (D070172)
1. Increased the length of side arms. The overall height of D070172 assembly matches that of D960001.
2. The files are present in dropbox in [40mShare] > [40m_cad_models] > [TT - Tip Tilt Suspension]
13560   Fri Jan 19 15:22:19 2018 Udit KhandelwalSummaryGeneral40m CAD update 2018/01/19

1. All parts will be now named according to the numbering system in this excel sheet: LIGO 40m Parts List in dropbox folder [40mShare] > [40m_cad_models] > [40m Lab CAD]
2. I've placed optical tables in the chambers at 34.82" from the bottom for now. This was chosen by aligning the centre of test mass of SOS assembly (D960001) with that of vacuum tube (Steve however pointed out last week they might not necessarily be concentric).

13561   Fri Jan 19 20:59:07 2018 Udit KhandelwalUpdateGeneralSolidworks Rendering

Rendered the SOS assembly (D960001) with correct materials and all and it looks very nice. Will extend this to the building cad later.

13601   Fri Feb 2 21:12:46 2018 Udit KhandelwalSummaryGeneralSummary - 2018/02/02

Discussed with Koji about motivation to simplify the design of this assembly, which has many unnecessary over-constraints. I have started to cad alternate parts with the aim of removing these over-constraints.

Acquired a stack of original engineering drawings of the vacuum chambers from Steve which I will take home, get scanned, and then use as reference for the cad i'm working on.

Other:
Started paperwork at west bridge office to get paid as an "occasional employee". Hopefully I receive old money.

13638   Fri Feb 16 21:03:17 2018 Udit KhandelwalSummaryGeneralSummary 2018/02/16

Updated the dimensions of and fleshed out the chambers in greater detail, by referring to the engineering drawings that Steve gave to me. I have scanned and uploaded most of these drawings to Dropbox in [40mShare]>[40m_cad_models]>[Vacuum Chamber Drawing Scans]. The excel file "LIGO 40m Parts List" in the [40m Lab CAD] folder also lists the Steve drawings I referenced for dimensions of each part.

Next steps:
1. Finish details of all chambers.
2. Start placing representative blocks on the optical table.

13654   Fri Feb 23 20:46:04 2018 Udit KhandelwalSummaryGeneralCAD Summary 2018/02/23

I have more or less finished cadding the test mass chamber by referring to the drawings Steve gave me. Finer details like lugs and bolts and window flaps can be left for later. Here's a quick render:

13677   Fri Mar 9 20:35:41 2018 Udit KhandelwalSummaryGeneralSummary 2018/03/09

1. Optical Table Layout

I had discussed with Koji a way to record coordinates of optical table equipments in a text file, and load to solidworks. The goal is to make it easier to move things around on the table in the CAD. While I have succeeded in importing coordinates through txt files, there is still a lot of tediousness in converting these points into sketches. Furthermore, the task has to be redone everytime a coordinate is added to or changed in the txt file. Koji and I think that this can all be automated through solidworks macros, so I will explore that option for the next two weeks.

2. Vacuum Chamber CADs

Steve will help find manufacturing drawings of the BS chamber. I have completed the ETM chambers, while the ITM ones are identical to them so I will reuse parts for the CAD.

13865   Fri May 18 18:14:18 2018 Udit KhandelwalSummaryGeneralSummary 05/18/2018

Tip-Tilt Suspension Design:

Designed a new ECD plate and changed dimensions of the side arms after discussing with Koji. After getting feedback on the changes, I will finish the assembly and send it to him to get approved for manufacturing.

13884   Wed May 23 19:24:37 2018 Udit KhandelwalSummaryGeneralSummary 05/23/2018

Tip-Tilt Redesign Project with Koji:

Did further itirations to the ECD backplate. Going to determine minimum thickness between magnet hole and plus sign for eddy current damping.

Chamber optical table layouts

Finished the positioning of optics and instruments in SolidWorks for the Vertex chambers. The reference for positioning is "40m_upgrade_layout_Dec2012.dwg", and solidworks files I created are in the main 40m CAD folder.

13996   Thu Jun 21 14:23:22 2018 Udit KhandelwalSummaryGeneralA summary of the Tip-TIlt Mirror Holder design changes

Here’s a quick summary of the Tip-Tilt Design updates (all files are in the dropbox in [TipTiltSus>TT_New]) that I have been working on with Koji and Steve's help.

1. Plate on top to hold mirror in place:

The plate is 0.5 mm thick. I did a rough FEA with 10 N force on the point of pressure on it, and it bent easily.

2. Weighted screw rod at the bottom for tilting the mirror-holder:

I did a very simplified free body analysis to calculate the required length of the rod to achieve a +/- 15 mRad tilt, and got around 1.5 inches.

3. Set-screws on both side of wire clamp to adjust its horizontal position:

• Front view (showing set screws on either side of the clamp to push it into the desired position, and the clamp in the middle with screws on top and bottom to fix its position):

• Exploded view showing protrusion in clamp that sits in the mirror holder inset:

• Exploded view showing inset in the mirror holder to slide protrusion in:

1. Used the same screw size in most places to reduce complexity.

2. The mirror holder I have worked on is a little different from the actual piece I have on my table. Which one do you prefer (Koji)?

14042   Fri Jul 6 19:39:37 2018 Udit KhandelwalSummaryGeneralCAD drawings of cantilever suspension required

Request to Koji to acquire the drawings or 3D CAD of the cantilever suspensions of the Tip-Tilt Assembly!

14047   Mon Jul 9 17:29:28 2018 Udit KhandelwalSummaryTip-TIltTipTilt mirror holder final changes

Final Summary of changes to mirror holder in Tip-Tilt holder.

Determining minimum range for Side Clamp:

1. The initial distance b/w wire-release point and mirror assembly COM = 0.265 mm

2. But this distance is assuming that wire-release point is at mid-point of clamp. So I'm settling on a range of +/- 1mm. The screenshots below confirm range of ~1mm between (1) side screw & protrusion and (2) clamp screw and clamp.

Determining length of tilt-weight assembly rod at the bottom to get $\pm$ 20mRad range

The tilt-weight assembly is made from following Mcmaster parts:
Rod   - 95412A864 18-8 SS  #2-56 Threaded Rod
Nuts  - 91855A103 18-8 SS #2-56 Acorn Cap Nut

Since the weights are fixed, only rod length can be changed to get the angle range.

$tan \theta =\frac{d}{h}$

$d= h \times tan\theta = 34.25\text{mm} \times tan(20 \text{mRad}) = 0.69 \text{mm}$
So a range of 1 mm between nut's inner face and mirror-holder face should be enough. Since holder is 12 mm thick, rod length = 12mm + 2 x 1mm + 2 x (nut length) = 12 + 2 + 9.6 = 23.6 mm = 0.93 inch. So a 1" rod from Mcmaster will be fine.

6161   Tue Jan 3 17:46:38 2012 Updated Stewart platform design requirementsUpdateGeneralUpdated design requirements for a Stewart platform

I updated the design requirements for the Stewart platform.  I weighed the unloaded "dirty" SOS that was sitting on the workbench in the control room; its mass is 11 kg.  Steve suggested that the OSEMs (not installed on this model) would add another 0.5 kg.  From the specs in the final SOS design document, LIGO-T970135, I added 0.25 kg for the optic itself; I am therefore taking the total payload mass to be 11.75 kg.  (Now, the upper stage of the Stewart platform itself will likely add a nontrivial amount, but I am not worrying about this yet.)

I have e-mailed Janeen Romie to obtain the actual center of mass and principal moments of inertia of the platform.  I also cooked up a simple scheme to measure both quantities, should this information not be available.  It would involve rigidly mounting the dirty SOS to a rigid bar hung from a pivot.  By translating the mount point in two dimensions and measuring the period of the pendulum, I ought to be able to find the center of mass and moments of inertia by multilinear regression.  However, this elaborate scheme is not necessary to just compute some ballpark figures; it could wait until a later stage in the design.  For the time being, I just rescaled the moment of inertia proportional to the increase in mass, such that the torque-to-force ratio is unchanged.

As such, the design requirements are now

• linear travel: 40 microns peak to peak (based on SOS design requirements in LIGO-T950011)
• angular travel: 3 mrad peak to peak (based on SOS design requirements in LIGO-T950011)
• payload mass: 11.75 kg (measured unloaded mass, plus educated guesses about combined mass of OSEMs and optic)
• payload moment of inertia: 0.0232 kg m^2 (wild guess)
• bandwidth: 500 Hz (suggestion of Rana and Koji: ~kHz)

From these assumptions, the revised actuator requirements and dimensions are:

• peak actuator force: 2.04 kN
• minimum radius of top platform: 15 cm
• minimum radius of bottom platform: 30 cm
• minimum height: 26 cm

See the attached PDF document.

It appears that the actuator that I had originally nominated, PI's model P-225.80, would very nearly meet the actuator force requirement.  Steve also pointed out the following single-axis shakers that are already in use in the 40m:

• Brüel & Kjær type 4809
• Brüel & Kjær type 4810

I want to find out if either of these would meet the present need, but I'm waiting on a response from the manufacturer to get access to the data sheets.

ELOG V3.1.3-