40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 333 of 336  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  16690   Tue Mar 1 19:26:24 2022 KojiUpdateSUSETMY SUS Electronics Replacement

The replacement key switches and Ne Indicators came in. They were replaced and work fine now.

The power supply units were tested with the X end HeNe display. It turned out that one unit has the supply module for 1350V 4.9mA while the other two do 1700V 4.9mA.
In any case, these two ignited the HeNe Laser (1103P spec 1700V 4.9mA).

The 1350V one is left at the HeNe display and the others were stored in the cabinet together with spare key SWs and Ne lamps.

Attachment 1: PXL_20220302_025723651.jpg
PXL_20220302_025723651.jpg
Attachment 2: PXL_20220302_030102033.MP.jpg
PXL_20220302_030102033.MP.jpg
  16691   Tue Mar 1 20:38:49 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

During my investigation, I inadvertently overwrote the serial port configuration for the connected devices. So I am now working to get it all back. I have attached screenshots of the config settings that brought back communication that is not garbled. There is no physical connection to port 6, which I guess was initially used for the UPS serial communication but not anymore. Also, ports 9 and 10 are connected to Hornet and SuperBee, both of which have not been communicating for a while and are to be replaced, so there is no way to confirm communication with them. Otherwise, the remaining devices seem to be communicating as before.

I still could not establish communication with the XGS-600 controller using the serial port settings given in the manual, which also happen to work via Serial to USB adapter, so I will revisit the problem later. My immediate plan is to do a Serial Ethernet, then Ethernet to Serial, and then Serial to USB connection to see if the USB code still works. If it does then at least I know the problem is not coming from the Serial to Ethernet adapters. Then I guess I will replace the controller with my laptop and see what signal comes through when I send a message to the controller via the IOLAN serial device server. Hopefully, I can discover what's wrong by this point.

 

Note to self: Before doing anything, do a sanity check by comparing the settings on the IOLAN SDS and the config settings that worked for the Serial to USB communication and post an elog for this for reference.

Attachment 1: Working_Serial_Port_List_1.png
Working_Serial_Port_List_1.png
Attachment 2: Working_Serial_Port_List_2.png
Working_Serial_Port_List_2.png
Attachment 3: Working_Config_Ports#1-5.png
Working_Config_Ports#1-5.png
Attachment 4: Working_Config_Ports#7-8.png
Working_Config_Ports#7-8.png
  16692   Wed Mar 2 11:50:39 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

Here is the IOLAN SDS TCP socket setting and the USBserial setting for comparison.

I have also included the python script and output from the USBserial test from earlier.

Attachment 1: XGS600_IOLAN_settings_1.png
XGS600_IOLAN_settings_1.png
Attachment 2: XGS600_IOLAN_settings_2.png
XGS600_IOLAN_settings_2.png
Attachment 3: XGS600_USBserial_settings.png
XGS600_USBserial_settings.png
Attachment 4: XGS600_comm_test.py
#!/usr/bin/env python

#Created 2/24/22 by Tega Edo
'''Script to read/write to the XGS-600 Gauge Controller'''

import serial
import sys,os,math,time

ser = serial.Serial('/dev/cu.usbserial-1410') # open serial port 

... 74 more lines ...
Attachment 5: XGS600_comm_test_result.txt
----- Multiple Sensor Read Commands -----

Sent to XGS-600 -> #0001\r : Read XGS contents
response : >FE4CFE4CFE4C

Sent to XGS-600 -> #0003\r : Read Setpoint States
response : >0000

Sent to XGS-600 -> #0005\r : Read software revision
response : >0206,0200,0200,0200
... 69 more lines ...
  16693   Wed Mar 2 12:40:08 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

Connector Test:

A quick test to rule out any issue with the Ethernet to Serial adapter was done using the setup shown in Attachment 1. The results rule out any connector problem.

 

IOLAN COMM test (as per Koji's suggestion):

The next step is to swap the controller with a laptop set up to receive serial commands using the same settings as the XGS600 controller. Basically, run a slightly modified version of python script where we go into listening mode. Then send commands to the TCP socket on the IOLAN SDS unit using c1vac and check what data makes its way to the laptop USBserial terminal. After working on this for a bit, I realized that we do not need to do anything on the c1vac machine. We only need to start the service as it would work normally. So I wrote a small python code for a basic XGS-600 controller emulator, see Attachment 4. The outputs from the laptop and c1vac terminals are Attachments 5 and 6 respectively. 

These results show that we can communicate via the assigned IP address "192.168.114.22" and the commands that are sent from c1vac reaches the laptop in the correct format. Furthermore, the serial_XSG service, a part modbusIOC_XGS service, which usually exits with an error seems fine now after successfully communicating with the laptop. I don't know why it did not die after the tests. I also found a bug in my code as a result of the test, where the status field for the fourth gauge didn't get written to. 

 

Pressure reading issue:

I noticed that the pressure reading was not giving the atmospheric value of ~760 Torrs as expected. Looking through my previous readouts, it seems the unit showed this atm value of ~761 Torrs when the first gauge was attached. However, a closer look at the issue revealed a transient behavior, i.e. when the unit is turned on the reading dips to atm value but eventually rises up to 1000 Torrs. I don't think this is a calibration problem bcos the value of 1000 Torrs is the maximum value for the gauge range. I also found out that when the XGS-controller has been running for a while, a power cycle does not have this transient behavior. So maybe a faulty capacitor somewhere? I have attached a short video clip that shows what happens when the XGS-controller unit is turned on.

Attachment 1: IMG_20220302_123529382.jpg
IMG_20220302_123529382.jpg
Attachment 2: XGS600_Serial2Ethernet2Serial2USB_comm_test_result.txt
$ python3 XGS600_comm_test.py  

----- Multiple Sensor Read Commands -----

Sent to XGS-600 -> #0001\r : Read XGS contents
response : >FE4CFE4CFE4C

Sent to XGS-600 -> #0003\r : Read Setpoint States
response : >0000

... 73 more lines ...
Attachment 3: VID-20220302-WA0001.mp4
Attachment 4: comm_test_c1vac_to_laptop_via_iolansds.py
#!/usr/bin/env python

#Created 3/2/22 by Tega Edo
'''Script to emulate XGS-600 controller using laptop USBserial port'''

import serial
import sys,os,math,time

ser = serial.Serial('/dev/cu.usbserial-1410') # open serial port 

... 19 more lines ...
Attachment 5: laptop_terminal.txt
(base) tega.edo@Tegas-MBP serial % python3 comm_test_c1vac_to_laptop_via_iolansds.py

----- Listen for USBserial command and asynchronously send data in XGS600 format -----

Command received from c1vac [1] : 

Data sent to c1vac [1] : >1.000E+00,NOCBL    ,NOCBL    ,NOCBL    ,2.00E+00,NOCBL\r
Command received from c1vac [2] : 

Data sent to c1vac [2] : >2.000E+00,NOCBL    ,NOCBL    ,NOCBL    ,3.00E+00,NOCBL\r
... 54 more lines ...
Attachment 6: c1vac_terminal.txt
controls@c1vac:/opt/target/python/serial$ caget C1:Vac-FRG1_status && caget C1:Vac-FRG2_status && caget C1:Vac-FRG3_status && caget C1:Vac-FRG4_status && caget C1:Vac-FRG5_status
C1:Vac-FRG1_status             1.530E+02
C1:Vac-FRG2_status             OFF
C1:Vac-FRG3_status             OFF
C1:Vac-FRG4_status             NO COMM
C1:Vac-FRG5_status             1.55E+02
controls@c1vac:/opt/target/python/serial$ caget C1:Vac-FRG1_status && caget C1:Vac-FRG2_status && caget C1:Vac-FRG3_status && caget C1:Vac-FRG4_status && caget C1:Vac-FRG5_status
C1:Vac-FRG1_status             1.630E+02
C1:Vac-FRG2_status             OFF
C1:Vac-FRG3_status             OFF
... 70 more lines ...
  16694   Wed Mar 2 14:02:43 2022 YehonathanUpdateBHDRe-susspension of AS1

Yesterday, I rebuilt the OpLev setup in the cleanroom in order to suspend AS1. It took me a while to find all the necessary parts but I found them in the end.

The HeNe laser was placed on the optical table and turned on. The beam was aimed to bounce off a folding mirror to the SOS tower.

The beam's height was controlled by the HeNe laser stage and made to be 5+14/32". The beam from the folding mirror was made parallel to the table, first with an iris and then with the QPD connected to a scope.

Preparing the SOS tower for the suspension I noticed that the wire clamp is scratched on both sides from previous suspensions. I discarded that wire clamp but couldn't find the spares. Time ran out and I had to stop.

  16695   Thu Mar 3 04:11:36 2022 KojiUpdateSUSETMY 1Y4 Electronics Replacement

For the Y-end electronics replacement, we want to remove unused power supplies. In fact, we already removed the +/-5V supplies from the stack. I was checking what supply voltages are used by the Eurocard modules. I found that D990399 QPD whitening board had the possible use of +/-5V.

The 40m Y-end version can be found here D1400415. The +/-5V supply voltages are used at the input stage AD620 and the QPD bias voltage of -5V.

AD620 can work with +/-15V. Also the bias voltage can easily be -15V. So I decided to cut the connector legs and connected +5V line to +15V, and -5V line to -15V.

With this modification, I can say that the eurocards only use the +/-15V voltages and nothing else.

The updated schematics can be found as D1400415-v6

Attachment 1: PXL_20220303_082726693.jpg
PXL_20220303_082726693.jpg
Attachment 2: PXL_20220303_082752494.jpg
PXL_20220303_082752494.jpg
Attachment 3: PXL_20220303_082744464.jpg
PXL_20220303_082744464.jpg
  16696   Thu Mar 3 04:24:23 2022 KojiUpdateSUSETMY 1Y4 Electronics Replacement

The DC power strip at Y-end was connected to the bottom two Sorensen power supplies. They are configured to provide +/-18V.

 

Attachment 1: PXL_20220303_094421604.jpg
PXL_20220303_094421604.jpg
Attachment 2: PXL_20220303_094435127.jpg
PXL_20220303_094435127.jpg
  16698   Thu Mar 3 17:09:46 2022 PacoUpdateBHDRe-susspension of AS1

[Anchal, Paco]

Wire clamp spare was installed, furthermore AS1 was reinstalled on adapter, attached wire clamps, and cleaned using ionized air gun. Finally, we suspended it on the SOS tower and left it resting on the bottom earthquake stops; ready for balancing.

Quote:

Yesterday, I rebuilt the OpLev setup in the cleanroom in order to suspend AS1. It took me a while to find all the necessary parts but I found them in the end.

The HeNe laser was placed on the optical table and turned on. The beam was aimed to bounce off a folding mirror to the SOS tower.

The beam's height was controlled by the HeNe laser stage and made to be 5+14/32". The beam from the folding mirror was made parallel to the table, first with an iris and then with the QPD connected to a scope.

Preparing the SOS tower for the suspension I noticed that the wire clamp is scratched on both sides from previous suspensions. I discarded that wire clamp but couldn't find the spares. Time ran out and I had to stop.

 

  16699   Thu Mar 3 17:21:11 2022 Ian MacMillanUpdateSUSETMY 1Y4 Electronics Replacement

[Koji, Ian]

1) We attached the 30 coil driving cables to the vacuum feed through to the sat amp  [40m wiki] they run along the cable tray then up and down into the rack.

2) we checked all DB and power cables. We found that the anti-imaging filter had a short and got very hot when plugged in. the back power indicator lights turned on fine but the front panel stayed off. We removed it and replaced it with the one that was on the test stand marked for the BHD. This means we need to fix the broken one and Koji mentioned getting another one.

3) we reassigned the ADC and DAC channels in the iscey model and the asy model. we committed a version before we made any changes.

4) Finally we tested the setup to make sure the ETM was being damped.

Next step:

1) Measure the change of the PD gains and the actuator gains. See pervious elog

  16701   Fri Mar 4 18:12:44 2022 KojiUpdateVACRGA pumping down

1. Jordan reported that the newly installed Pirani gauge for P2 shows 850Torr while PTP2 show 680 Torr. Because of this, the vacuum interlock fails when we try to open V4.

2. Went to c1vac. Copied the interlock setting file interlock_conditions.yaml to interlock_conditions_220304.yaml
3. Deleted diffpressure line and pump_underspeed line for V4
4. Restarted the interlock service

controls@c1vac:/opt/target/python/interlocks$ sudo systemctl status interlock.service  
controls@c1vac:/opt/target/python/interlocks$ sudo systemctl restart interlock.service
controls@c1vac:/opt/target/python/interlocks$ sudo systemctl status interlock.service

5. The above 2~4 was unnecessary. Start over.


Let RP1/3 pump down TP1 section through the pump spool. Then let TP2 pump down TP1 and RGA.

1. Open V7. This made P2 a bit lower (P2 is alive) and P3.
2. Connected the main RP tube to the RP port.
2. Started RP1/3. PRP quickly reaches 0.4Torr.
3. Opened V6 this made P3 and O2 below 1Torr.
4. Close V6. Shutdown RP1/3. Disconnect the RP tube.
5. Turn on auxRP at the wall powe
6. Turn on TP2. Wait for the starting up.
7. Open V4. Once the pressure is below Pirani range, open VM3.
8. Keep it running over the weekend.

9. Once TP2 reached the nominal speed, the "StandBy" button was clicked to lower the rotation speed (for longer life of TP2)

Attachment 1: Screenshot_2022-03-04_19-38-11.png
Screenshot_2022-03-04_19-38-11.png
  16703   Sat Mar 5 02:03:46 2022 KojiUpdateSUSETMY 1Y4 Electronics Replacement

Oplev saga

Summary

- The new coil driver had not enough alignment range to bring the oplev beam back to the QPD center
- The coil driver output R was reduced from 1.2k to 1.2k//100 = 92.3 +/- 0.4 Ohm
- Now the oplev spot could be moved to the center of the QPD

- The damping gains (POS/PIT/YAW) and the oplev gains were reduced by a factor of 1/10.
- The damping and the oplev servos work now. Fine gain tuning is necessary.

To Do:
- DC value / TF measurements
- Adjust damping gains
- RFM issue
- Connection check
- Cable labeling


== Alignment Range ==

- Since c1auxey was removed, we no longer have C1:SUS-ETMY_PIT_COMM and C1:SUS-ETMY_YAW_COMM. At this moment, all the alignment is taken with the offset input from the fast real-time system via C1:SUS-ETMY_PIT_OFFSET and C1:SUS-ETMY_YAW_OFFSET.

- The oplev spot could not be moved on the center of the QPD without exceeding the DAC output range (~+ or -32000) for the coils. (Attachment 1)

- This is because the old system had a slow but large current range (Rout = 100) and a small current range for the fast control. Until we commission the new HV BIAS Driver, we have to deal with the large DC current with the HAM-A coil driver.

== Modification to the output resistances ==

The following units and the channels were modified. Each channel had a differential current driver and two output resistances of 1.2K. 100Ohm (OHMITE 43F100, 3W) wire wound resistors were added to them in parallel, making the resulting output R of ~92Ohm.

- ETMY HAM A Coil Driver 1: S2100622 (Attachments 2/3) CH1/2/3
- ETMY HAM A Coil Driver 2: S2100621 (Attachments 4/5) CH3

- This modification allowed me to align the oplev spot to the center of the QPD. C1:SUS-ETMY_PIT_OFFSET and C1:SUS-ETMY_YAW_OFFSE are +2725 (8%FS) and -2341 (7%FS), respectively.
- The previous alignment slider values were -0.9392 and 0.7615 (out of 10). These are the reasonable numbers, considering the change of the Rout from 100 to 92Ohm, and the sign flip.
(By the way, autoBurt files for c1auxex and c1auxey were not properly configured and the history of C1:SUS-ETM*_*_COMM was not recorded.)

== Damping Servos ==

- Now, the POS/PIT/YAW servos experience ~x10 gains. So temporarily these gains were reduced (POS 20->2, PIT 6->0.6, YAW 4->0.4) and the loops are stable when engaged.
- Also the gains of the OPLEV servos were reduced from -4.5 to -0.45. The loops are stable when engaged.

== Snapshot of the working condition ==

Attachent 6 shows the screenshot for the snapshot of the working condition.


To Do

- The damping servos were tested without proper PD whitening compensation.
  -> It turned out this is not necessary as our modified PD whitening has the pole and zero at the same freqs as before.

- Compare the DC values of the OSEM outputs and compensate for the gain increase by the "cts2um" filter.

- The end RTS suffers from the RFM issue. There is no data transmitted from the vertex to the end. I suspect we need to restart the c1rfm process. But this will likely suspend all the vertex real-time machines. Careful execution is necessary.

- c1iscey has all the necessary analog connections. But they are not tested. When we lock the green/IR cavity, we'll need them.

- The cable labeling is only half done.

Attachment 1: oplev_spot.jpg
oplev_spot.jpg
Attachment 2: PXL_20220305_090003837.jpg
PXL_20220305_090003837.jpg
Attachment 3: PXL_20220305_090023436.jpg
PXL_20220305_090023436.jpg
Attachment 4: PXL_20220305_091232290.jpg
PXL_20220305_091232290.jpg
Attachment 5: PXL_20220305_091306604.MP.jpg
PXL_20220305_091306604.MP.jpg
Attachment 6: Screenshot_2022-03-05_01-37-26.png
Screenshot_2022-03-05_01-37-26.png
  16704   Sun Mar 6 18:14:45 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

Following repeated failure to establish communication between c1vac and the XGS600 controller via Perle IOLAN serial device server, I decided to monitor the signal voltage of the communication channels (pin#2, pin#3 and pin#5) using an oscilloscope. The result of this investigation is presented in the attached pdf document. In summary, it seems I have used a crossed wired RS232 serial cable instead of a normal RS232 serial cable, so the c1vac read request command is being relayed on the wrong comm channel (pin#2 instead of pin#3). I will swap out the cable to see if this resolves the problem.  

Attachment 1: iolan_xgs_comm_investigation.pdf
iolan_xgs_comm_investigation.pdf iolan_xgs_comm_investigation.pdf iolan_xgs_comm_investigation.pdf iolan_xgs_comm_investigation.pdf
  16705   Mon Mar 7 10:06:32 2022 YehonathanUpdateIOOIMC unlocked again, completely misaligned

Came this morning and saw that the IMC is unlocked.

Went into MC Lock screen and see that the watchdog is down and the PSL shutter is closed. I tried to open the shutter but nothing happened - no REFL signal or beam on the MC REFL camera .

Thinking this has something to do with the watchdog I upped the watchdog:

ezcawrite C1:SUS-MC2_LATCH_OFF 1

The watchdog on the MEDM screen became green but the shutter still seemed unresponsive. I went to the PSL table and made sure that the shutter is working. I opened the AS table and saw there no MC REFL beam anywhere.

Thinking that MC1 must be completely misaligned I opened the MC align screen to find that indeed all the alignment values has been zeroed! (attachment).

I burt restore c1iooepics from Mar 4th 00:19. Didn't help.

I try to burt restore c1susepics from Mar 1st 13:19. Still zero.

I try to burt restore c1susaux from Mar 1st 00:19 -> seems like alignment values have been restored.

I open the shutter. Beam is flying! MC Watchdogs tripped! I close the shutter. OK, I need to wait until the MCs are dampped enough. MC2 and MC3 have relaxed so I enable their watchdogs. MC1 is still swinging a bit. I turn on damping for MC1 as well.

 

MC locked immediately but the REFL is still high like 1.2. Is it normal?

I turn on the WFSs and the REFL went down to 0.3 nice. I run the MC WFS relief script.

Attachment 1: Screenshot_2022-03-07_10-15-19.png
Screenshot_2022-03-07_10-15-19.png
  16706   Mon Mar 7 13:53:40 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

So it appears that my deduction from the pictures of needing a cable swap was correct, however, it turns out that the installed cable was actually the normal RS232 and what we need instead is the RS232 null cable. After the swap was done, the communication between c1vac and the XGS600 controller became active. Although, the data makes it all to the to c1vac without any issues, the scope view of it shows that it is mainly utilizing the upper half of the voltage range which is just over 50% of the available range. I don't know what to make of this.

 

I guess, the only remaining issue now is the incorrect atmospheric pressure reading of 1000 Torrs. 

 

Quote:

Following repeated failure to establish communication between c1vac and the XGS600 controller via Perle IOLAN serial device server, I decided to monitor the signal voltage of the communication channels (pin#2, pin#3 and pin#5) using an oscilloscope. The result of this investigation is presented in the attached pdf document. In summary, it seems I have used a crossed wired RS232 serial cable instead of a normal RS232 serial cable, so the c1vac read request command is being relayed on the wrong comm channel (pin#2 instead of pin#3). I will swap out the cable to see if this resolves the problem.  

 

Attachment 1: iolan_xgs_comm_live.pdf
iolan_xgs_comm_live.pdf
  16707   Mon Mar 7 14:52:34 2022 KojiUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

Great trouble shoot!

> I guess, the only remaining issue now is the incorrect atmospheric pressure reading of 1000 Torrs. 

This is just a calibration issue. The controller should have the calibration function.
(The other Pirani showing 850Torr was also a calibration issue although I didn't bother to correct it. I think the pirani's typically has large distribution of the calibration values and requires individual calibration)

  16708   Mon Mar 7 14:55:33 2022 KojiUpdateIOOIMC unlocked again, completely misaligned

Hmm, the bias values were reset at 2022-03-03-20:01UTC which is 2022-03-03-12:01 PST with no apparent disruption of the data acquisition (= no resetting of the RTS). Not sure how this could happen.

 

  16709   Mon Mar 7 16:44:15 2022 Ian MacMillanUpdateSUSETMY SUS Electronics Replacement

Now that the ETMSUS is back up and running I reran my measurements from the beginning of the process. The results below show a change in gain between the before and after measurements. I have given values of the low-frequency section below.

Average Gain difference from the TFs: 18.867  (excluding thee side change)

  Before After Gain difference
UL -31 dB -5 dB 19.952
UR -36 dB -10 dB 19.952
LR -27 dB -2 dB 17.782
LL -37 dB -12 dB 17.782
SIDE -48 dB -45 dB 1.412

I also am noting the new values for the OSEM DC output: average gain increase: 9.004

OSEM DC OFFSET Before DC OFFSET After Gain increase
UL 557 5120 9.19
UR 568 5111 8.99
LR 780 7041 9.02
LL 385 3430 8.91
SD 328 2922 8.91

In addition, the oplev position was:

  Before After
 OPLEV_PERROR -16.055 -16.715
 OPLEV_YERROR -6.667 -16.597

All data and settings have been included in the zip file

From the average gain increase of the TFs which indicates the increase of the whole system and the increase in gain from the OSEM we can calculate the gain from the actuators.

18.867/9.004 = 2.09

thus the increase in gain on the actuator is about 2.09

EDIT: I updated the side TF with one with better SNR. I increased the excitation amplitude.

Attachment 1: UR_TF_Graph.pdf
UR_TF_Graph.pdf
Attachment 2: UL_TF_Graph.pdf
UL_TF_Graph.pdf
Attachment 3: LR_TF_Graph.pdf
LR_TF_Graph.pdf
Attachment 4: LL_TF_Graph.pdf
LL_TF_Graph.pdf
Attachment 5: SD_TF_Graph.pdf
SD_TF_Graph.pdf
Attachment 6: 20220307_SUSElectronicsAfterTests.zip
  16710   Mon Mar 7 16:56:08 2022 YehonathanUpdateBHDRe-susspension of AS1

{Paco, Yehonathan}

We tried to roughly balance the adapter with two counterweights at the front, like with the other thin optics using an iris. As before, we couldn't get the beam above the iris hole no matter how much we inserted the counterweights into the adapter. We noticed that one of the side blocks is actually the one where the clearance for the wire was made on the wrong side. So there was clearance on both the up and bottom sides of the side block (see attachment 1).

Could this be the cause of the balancing issue? Running out of ideas on how to fix it we gave it a try and replaced it with a spare side block. We also found that the wire on the other side block was kinked so we replaced the wire on this one as well.

After inserting new wires into the side blocks, we hung the adapter on the winches and the beam was above the iris aperture! How could this tiny amount of missing mass make this much difference?

We were able to roughly balance the adapter.

We then tried to balance the roll of the adapter but accidentally knocked off the side magnet 😫.

We usually glue several side magnets together and they all together support the metallic plate on which the magnets are magnetically attached to. This time we had only one side magnet to glue so instead of trying to glue the magnet vertically we are trying to glue it horizontally using a flat surface and a stage to clamp it (attachments 2,3).

BTW, the HeNe was not working when we came into the cleanroom. We realized it was the old HeNe that we already determined to be broken but there was no sign on it. I attached a "BAD" sign on it and replaced it with the new HeNe. The OpLeve beam was realigned. All of this happened before all the things described above

Attachment 1: signal-2022-03-07-171520_001.png
signal-2022-03-07-171520_001.png
Attachment 2: signal-2022-03-07-172659_001.jpeg
signal-2022-03-07-172659_001.jpeg
Attachment 3: signal-2022-03-07-172659_003.jpeg
signal-2022-03-07-172659_003.jpeg
  16711   Mon Mar 7 18:53:16 2022 KojiUpdateBHDRe-susspension of AS1

Not sure if that small difference can cause the alignment inability. Particularly, the removed metal was just below the wire. This means that there is no misalignment effect at the first order.

Here is my idea:
You may be able to assist the alignment by adding washers on one side of the four holes to this "H" shaped parts. The holes are away from the center line, adding some weight definitely do some misalignment.

 

  16713   Tue Mar 8 12:08:47 2022 TegaUpdateVACOngoing work to get the FRG gauges readouts to EPICs channels

OMG, it worked! It was indeed a calibration issue and all I had to do was press the "OK" button after selecting the "CAL" tab beside the pressure reading. Wow.

Quote:

Great trouble shoot!

> I guess, the only remaining issue now is the incorrect atmospheric pressure reading of 1000 Torrs. 

This is just a calibration issue. The controller should have the calibration function.
(The other Pirani showing 850Torr was also a calibration issue although I didn't bother to correct it. I think the pirani's typically has large distribution of the calibration values and requires individual calibration)

 

Attachment 1: XGS600_calibration.pdf
XGS600_calibration.pdf
  16714   Tue Mar 8 12:24:13 2022 YehonathanUpdateBHDRe-susspension of AS1

The gluing seemed to be successful. I assembled the side block with the magnet on the adapter. Paco helped me hang the adapter on the SOS tower.

The height and roll of the adapters were balanced (attachment 1,2).

The QPD was placed at the beam reflection. The beam was centered horizontally on the QPD and then measured vertically. The pitch DOF was balanced using the counterweights. The counterweight was locked. Balance was retained.

I tried to assemble the upper mirror clamp on the tower but for some reason, one of its tap holes was not able to accept screws. I gave it to Jordan for retapping. I measured the motion spectrum using the QPD connected to a scope (attachment 3).

Major peaks are at 668mHz, 942mHz, and 1029mHz.

 

Attachment 1: AS1_Roll_Balance.png
AS1_Roll_Balance.png
Attachment 2: AS1_Height_Balance.png
AS1_Height_Balance.png
Attachment 3: FreeSwingingSpectra_new.pdf
FreeSwingingSpectra_new.pdf
  16715   Tue Mar 8 19:29:36 2022 PacoUpdateBHDRe-balance of AS1

[Paco]

Installed AS1 in vacuum, near the center of the table, and installed the OSEMs. All OSEMS are "balanced" nominally, i.e. their shadow is at the halfway point optimum, but fine tuning is required, which I will attempt tomorrow after restoring the AS1 suspension screen settings. Today, I tried damping the SIDE DOF, but didn't succeed, although there was definitely some oscillating behaviour with high (> 5) gains on the damping, so I believe this is a matter of patience. For now, all OSEMs are looking ok, the SOS is in place, and hopefully it will soon be damped. 

  16716   Wed Mar 9 09:35:26 2022 PacoUpdateBHDRe-balance of AS1

[Paco]

AS1 is installed, OSEMs balanced, and the optic damped successfully. We should run the free swinging test overnight to validate this re-installation.

  16717   Wed Mar 9 10:23:28 2022 JordanUpdateVACLeak Testing of New Manual Gate Valve - Attempt #1

Jordan, Chub, Paco

Chub and I went into the lab this morning to leak check the new gate valve after pumping over the weekend. This would be done through the RGA and spraying helium around the newly installed flanges. The RGA is set to monitor the partial pressure of helium versus time and we visually watch for any spikes in pressure to indicate an air leak.

So, I mistakenly thought the gate valve was opened and both sides were being pumped on, this was not the case. The vavle was closed so there was a pressure differential whenI turned the handle it tripped the interlocks and closed V4. I closed VM3 to the RGA volume to prevent the filament from being damaged.

Then the medm screen for the vac controls started flashing rapidly, I closed the window and reopened the controls to find all the panels were white, but we could still see the read only vac screen. So Paco restarted c1vac and the controls were restored. V7 closed, but was then reopened.

We now need to restart pumping with the odd pressure differentials between V4 and VM3.

Plan

- TP2 turned off along with the AUX pump

- VM3 opened to vent RGA volume (RGA turned off, filament cooled)

- Open the manual vent screw on TP1 to bring the RGA+TP1 volume back to atmosphere, now no pressure diff. on V4

- Open V4, restart AUX pump to rough out the volume

- Connect RP1/3 line to the pump scroll, turn on RP1/3 RGA+TP1 volume went to mtorr

- Slowly open the manual gate valve

- Connect AUX pump to TP2 and rough out

- Restart TP2, once at speed open V4, close V6 and turn off RP1/3

Now we are pumping on the RGA/TP1 volume with TP2, leak check attempt #2 will happen tomorrow morning

  16718   Wed Mar 9 11:52:18 2022 YehonathanUpdateBHDSimplified BHD readout sketch on ITMY table

I have made an editable draw.io diagram of the planned simplified BHD setup on the ITMY table (see attached).  10 pts = 1 inch.

This is very sketchy but easily adjustable since we are removing everything but the ITMY Oplev from that table.

Attachment 1: ITMY_Table_Sketch.drawio.pdf
ITMY_Table_Sketch.drawio.pdf
  16719   Wed Mar 9 12:57:52 2022 KojiUpdateBHDSimplified BHD readout sketch on ITMY table

- BHD beams were already mixed in the chamber. So we don't need a BS on the table. (Probably there is no BS already)

- We don't need to split each BHD beam. One PD per BHD beam is OK for now.

- Check if the BHD paths have reasonable angles from the windows so that the beams do not hit the chamber wall.

- We need the POY path. POY indeed goes to the BS table

  16721   Thu Mar 10 09:39:59 2022 JordanUpdateVACLeak Testing of New Manual Gate Valve - Attempt #2

This morning Chub and I leak checked the manual gate valve with the RGA and helium. There was no change in the helium partial pressure while spraying helium around the flanges, all looks good.

 

I also took a 100 AMU analog scan, after the filament had warmed up overnight and the plot was quite noisy even with the lowest scan speed. I recommend this unit go back to SRS for a filament replacement/recalibration. I am worried yesterday's "vent" of the RGA volume may have burned the filament. See the comparison of yesterday's analog scan to today's below.

Attachment 1: 3-09-2022.PNG
3-09-2022.PNG
Attachment 2: 3-10-2022.PNG
3-10-2022.PNG
  16722   Thu Mar 10 10:05:49 2022 PacoUpdateSUSAS1 free swing test

[Paco, Ian]

  • Begin free swinging test for AS1 at 10:05 AM, set for ~ 2.04 hours.
    • Test failed because damping failed to disable.
  • Restart free swinging test for AS1 at 15:06, set for 2.04 hours.
    • Success (Attachment #1 shows the DOF input matrix diagonalization effect)

Of slight concern is the side to other degrees of freedom coupling, but this is definitely an improvement from last time.

Attachment 1: SUS_Input_Matrix_Diagonalization.pdf
SUS_Input_Matrix_Diagonalization.pdf
  16723   Fri Mar 11 16:43:03 2022 Ian MacMillanUpdateSUSETMY SUS Electronics Replacement

I updated the gain of the ct2um filter on the OSEMS for ETMY and decreased their gain by a factor of 9 from 0.36 to 0.04.

I added a filter called "gain_offset" to all the coils except for side and added a gain of 0.48.

together these should negate the added gain from the electronics replacement of the ETMY

  16725   Tue Mar 15 10:45:31 2022 PacoUpdateGeneralAssembled small in-vac optics

[Paco]

This morning I assembled LO3, LO4 and AS3 (all mirrors) onto polaris K1 mounts. The mounts stand as per this elog, on 4.5" posts with 0.5" Al spacers to match the beam heigth of 5.5". I also assembled ASL by adding a 0.14" Al spacer, and finally, recycled two DLC mounts (from the XEND flowbench) and posts to mount the 2 inch diameter beamsplitters BHDBS and AS2 (T=10%). I stored the previous 2" optics in the CVI and lambda optic cases and labeled appropriately.

  16731   Thu Mar 17 11:40:41 2022 PacoUpdateSUSETMY green PZT HV supply

[Anchal, Paco]

We installed a HV kepco power supply for the green PZT steering the YAUX beam. We did this in anticipation of the YARM alignment to take place this afternoon. We borrowed an unused DC power supply labeled "OMC Power spply" and made an appropriate SMA connection (Attachment #1), Then we set the Vset to 100.0 Volts and the current limit to 10 mA. Once we enabled the output we saw the 5.6 mA of current drawn by the eurocard in accordance with the wiki log (Attachment #2). 

It may not be possible to use the PZT as per this so this work may not have a direct impact on our upcoming alignment task.


We probably bumped the ethernet cable (martian network) on c1iscey, so the FE models stopped showing up on the medm screens. When we connected it back, it seemed like the FE kept running the model and only IPC showed error. We restarted the rtcds models on c1iscey and burtrestored to today morning 5:19 am.

burtwb -f /cvs/cds/rtcds/caltech/c1/burt/autoburt/today/05:19/c1scyepics.snap -l /tmp/controls_1220317_115006_0.write.log -o /tmp/controls_1220317_115006_0.nowrite.snap -v

ETMY is properly damping now and the oplev is roughly centered as well but the OPLEV Servos are off. We did not turn them on.
We should be able to carry out our cavity arm alignment today afternoon on both arms now.

  16732   Thu Mar 17 16:50:53 2022 PacoUpdateBHDXARM AUX alignment

[Ian, Paco]

We opened the ITMX chamber and

  • Inspected PR2 and LO1 and didn't see anything suspicious.
  • Took the EQ stops off ITMX in preparation for alignment

Alignment:

  • Ian started at the ETMX station, slightly tweaking the M1 M2 XAUX mirrors by hand and Paco on the ITMX chamber looking at the beam. The beam was visibly making it to the ITMX optic and reflecting back though at a negative pitch angle. No small motion on the M1-M2 knobs caused visible correction on this.
  • We decided to try adding an alignment offset to ITMX, and quickly saturated to 25000 (on the SUS screen) but fell short of fully correcting this PIT offset.
  • We scanned further the M1 M2 input alignment, and briefly lost the first reflection.
    • We recovered the first reflection, but the beam spot is now incident near the LL OSEM position.
  • We kept scanning M1 - M2 with Ian on the ITMX chamber this time, providing feedback through facetime.
  • Leaning on the ITMX chamber table, we noticed the magnitude of PIT correction left to be done and verified that M1-M2 two axis alignment + ITMX offsets should be enough for it.

We stopped our effort here, the XAUX beam spot is near the lower half of the ITMX face. Tomorrow, we will resume, but we will use airpods and a clean go-pro for real-time audiovisual feedback. Furthermore, ITMX OSEMs should be rebalanced as they haven't been touched after the table was balanced for PR2 and LO1.

  16735   Fri Mar 18 17:15:19 2022 PacoUpdateBHDXARM AUX alignment cont.

[Paco, Ian]

First, we re-balanced the ITMX OSEMs so that they would damp at around half-a-shadow.


Then, we set up a clean camera inside ITMX chamber looking at the ITMX optic. Then, using the live feed we aligned the AUX beam from the ETMX station using M1 and M2. The camera was great to help us align the beam properly close to the ITMX center. It wasn't very long until we could see a green beam on the IR card, but we didn't really see any flashing, so this may just be the bare transmission away from XARM resonance (Attachment #1).

Ian checked the reflection from ITMX using the IR card with holes, and he pretty much only saw one beam spot, so we turned to look for a beam scattering on the vacuum tube but didn't really see anything. This could mean that we were hitting the ETMX again, or missing slightly, or missing completely. We tried scanning the ITMX pitch and yaw using the bias (alignment) sliders, and with the illuminators off, try seeing some scattered green beam on the ETMX. We can't really see anything yet, but we will keep trying. If there are any tips on our method, it would be great to know them.

Attachment 1: Screen_Shot_2022-03-18_at_4.09.38_PM.png
Screen_Shot_2022-03-18_at_4.09.38_PM.png
  16738   Mon Mar 21 14:22:52 2022 AnchalUpdateSUSETMY Alignmnet offsets needed to be changed

I'm not sure why but the PIT and YAW offset values of +2725 and -2341 were not sufficient for the reflected OPLEV beam to reach the OPLEV QPD. I had to change the C1:SUS-ETMY_PIT_OFFSET to 5641 and C1:SUS-ETMY_YAW_OFFSET to -4820 to come back to center of the OPLEV QPD. We aligned the Oplevs to center before venting, so hopefully this is our desired ETMY position.

On another note, the issue of ETMY unable to damp was simple. The alignment offsets were on to begin with with values above 1000. This meant that whenever we enabled coil output, ETMY would necessarily get a kick. All I had to do was keep alignment offsets off before starting the damping and slowly increase the alignment offsets to desired position.

Quote:
 

- This modification allowed me to align the oplev spot to the center of the QPD. C1:SUS-ETMY_PIT_OFFSET and C1:SUS-ETMY_YAW_OFFSE are +2725 (8%FS) and -2341 (7%FS), respectively.

  16739   Mon Mar 21 18:00:05 2022 Ian MacMillanUpdateBHDXARM AUX alignment cont.

[Ian, Paco]

Continuing with the previous alignment that we stoped on friday, we re set up my heavily cleaned iPhone on FaceTime. The Phone alowed us to see the laser on the ITMX and center it on that optic.

  • We increased the trigger level for the watchdog on the optics.
  • Green beam was centered on th ITMX.
  • aligned the green laser: prompt reflection off of the ETMX to maximize the signal on the reflection PD
  • Went back to ITMX chamber, looked for the beam in the tube to see if the laser was hitting the beam tube off of the ITMX. From there we comunicated how to adjust the beam to move the beam towards the ETMX.
  • On the ETMX the reflection PD signal was measured and the ITMX was adjusted using CDS until ripples/"flashes" were seen in the reflection PD channel (C1:ALS-X_REFL_DC_OUT_DQ).
  • Once we saw flashing we tried to minimize the reflection pd signal using only ITMX alignment slider so that all the light was being held in the cavity.
  • Once we had this going the PDH lock engaged the higher order mode that we were seeing.
  • We removed the phone setup and closed up the ITMX chamber.
  • From here we moved to the control room and continude to adjust the ITMX and ETMX to see if we could lock to a lower order mode.
    • This proved unsuccessful so we will resume by trying to replicate the ASS action manually (with M1 - M2 PZT sliders and the REFL PD)
Attachment 1: PXL_20220322_015247138.jpg
PXL_20220322_015247138.jpg
  16743   Fri Mar 25 11:39:14 2022 AnchalUpdateSUSETMY SUS Electronics Replacement - Questions

After Ian updated the cts2um filters for OSEM, shouldn't the damping gains be increased back by factor of 10 to previos values? Was the damping gain for SIDE ever changed? we found it at 250.

Can you explain why gain_offset filter was required and why this wasn't done for the side coil?

Quote:

I updated the gain of the ct2um filter on the OSEMS for ETMY and decreased their gain by a factor of 9 from 0.36 to 0.04.

I added a filter called "gain_offset" to all the coils except for side and added a gain of 0.48.

together these should negate the added gain from the electronics replacement of the ETMY

 

  16746   Mon Mar 28 16:25:34 2022 Ian MacMillanUpdateSUSETMY SUS Electronics Replacement - Questions

The point of changing the gains was to return the system to its origional state. ie I wanted the over all gain of the physical components to be the same as when we started. From the CDS side of things nothing else should be changed. The damping filters should remain at their origional values. The cts2um filter was changed to counteract a change in the electronics (replacing them). These changes should cancel eachother out. As for the side control, on 3/4/22 koji reduced the output resistors for the 4 face OSEMs but did not change the the SD one. there fore the SD did not need the same adjustment as the others.

Quote:

After Ian updated the cts2um filters for OSEM, shouldn't the damping gains be increased back by factor of 10 to previos values? Was the damping gain for SIDE ever changed? we found it at 250.

Can you explain why gain_offset filter was required and why this wasn't done for the side coil?

Quote:

I updated the gain of the ct2um filter on the OSEMS for ETMY and decreased their gain by a factor of 9 from 0.36 to 0.04.

I added a filter called "gain_offset" to all the coils except for side and added a gain of 0.48.

together these should negate the added gain from the electronics replacement of the ETMY

 

 

  16748   Tue Mar 29 17:35:54 2022 PacoUpdateSUSDamping fix on BS, AS4, PR2, and PR3

[Ian, Paco]

  • We removed the "cheby" filters from AS4, PR2 and PR3 which had been misplaced after copying from the old SUS models. After removing them, the new SOS damped fine. Note that because of the Input matrices, the filters have to be enabled all at once for the MIMO loop to make sense.
  • We also disabled the "Cheby" filter on BS and saw it damp better. We don't understand this yet, but perhaps it's just a consequence of the many changes in the BSC that have rendered this filter obsolete.
  • we also reduced the damping gains on PR2, PR3 and AS4 to prevent overflow values. After the adjustments the optics were damping fine.
  16751   Fri Apr 1 14:26:50 2022 TegaUpdateOptical LeversSimplified sketch on MC table

Here is an early sketch of the MC table. 

 

Quote:

I have made an editable draw.io diagram of the planned simplified BHD setup on the ITMY table (see attached).  10 pts = 1 inch.

This is very sketchy but easily adjustable since we are removing everything but the ITMY Oplev from that table.

 

Attachment 1: MC_Table.drawio.pdf
MC_Table.drawio.pdf
  16752   Fri Apr 1 17:02:02 2022 KojiUpdateOptical LeversSimplified sketch on MC table

We are supposed to have BS Oplev Beams. We don't like the shallow angle reflections (i.e. AOI>45deg).

The laser is too big but I suspect the other components are too small. So it'd be check the actual size of the components including the optical mounts that are missing on the figure so far.

  16753   Fri Apr 1 22:22:29 2022 KojiUpdateOptical LeversSimplified sketch on MC table

Possibility to swap BS and ITMX tables:
BS table, which Tega said MC table, is 2ft x 4ft. The ITMX table is 3ft x 5ft and only the central 2ft x 4ft area is used. The area around the BS table is the narrowest for the east arm. We need at least (2+delta) ft of the hallway width so that we can move the instrument. I'm not yet sure if the ITMX table can be placed there without precise investigation.
 

  16755   Mon Apr 4 15:49:06 2022 TegaUpdateOptical LeversSimplified sketch on BS table

I have updated the BS table using feedback from Koji and Paco and the attached pdf document is the latest iteration.

Attachment 1: BS_Table.drawio.pdf
BS_Table.drawio.pdf
  16761   Thu Apr 7 11:47:22 2022 YehonathanUpdateBHDInitial BHD modeling: AS - LO mode matching

I begin modeling the initial BHD setup using Finesse. I started with copying C1_w_BHD.kat from the 40m/bhd repo and making changes to reflect the current BHD setup:

1. OMCs were removed.

2. Only 1 PD per BHD port was left.

3. Transmission of PR2 was changed to 2.2%. The PRG was calculated to be ~15.5.

4. Actual RoCs of new optics were dialed in (Yesterday me and Paco went into the cleanroom to measure the RoCs and they seem to match the datasheets).

Here's a table comparing the old (design?) RoCs with the new RoCs:

  New RoC Old RoC
LO1 5m 6m
LO2 inf inf
LO3 500mm 750mm
LO4 150mm -450mm
AS1 2m 2.8m
AS2 inf inf
AS3 200mm -2m
AS4 750mm 600mm
PR2 2000m -700m
PR3 1000m 1000m
SR3 1000m -700m

 

The changes looked quite alarming, especially for LO4 and AS3, so I wrote a script to calculate the mode matching between the LO and AS beams called AS_LO_ModeMatching.ipynb and pushed it into the repo. In the notebook a bright AS beam is created by creating a small asymmetry between the arms of ~ 0.003 degrees (~10pm). Amplitude detectors were put at the input ports of the BHD BS to calculate the fields in the AS and LO beams. In particular TEM00, TEM02 and TEM20 were measured for each beam.

The calculation shows that with the old RoCs the mode matching between the LO and AS beams is 99% while for the new RoCs it is ~ 50%.

  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.

Attachment 1: Screen_Shot_2022-04-07_at_8.40.23_PM.png
Screen_Shot_2022-04-07_at_8.40.23_PM.png
Attachment 2: Unknown-3.png
Unknown-3.png
Attachment 3: Unknown-4.png
Unknown-4.png
  16766   Thu Apr 7 21:15:04 2022 YehonathanUpdateBHDInitial BHD modeling: AS - LO mode matching

Ok, it turns out these optics were purchased on purpose, as this elog shows. Jon considered building a mode-matching telescope with stock optics as an initial step before purchasing the custom optics (referred to as "design" optics in my elog).

I dialed in the new distances between the optics into the .kat file as described in this elog and pushed the changes to the repo. With the new distances, I got mode-matching of 87% for the full IFO and 89% for FPMI so there's probably no need to worry as the mode-matching with these optics was already designed.

Quote:

I begin modeling the initial BHD setup using Finesse. I started with copying C1_w_BHD.kat from the 40m/bhd repo and making changes to reflect the current BHD setup:

1. OMCs were removed.

2. Only 1 PD per BHD port was left.

3. Transmission of PR2 was changed to 2.2%. The PRG was calculated to be ~15.5.

4. Actual RoCs of new optics were dialed in (Yesterday me and Paco went into the cleanroom to measure the RoCs and they seem to match the datasheets).

Here's a table comparing the old (design?) RoCs with the new RoCs:

  New RoC Old RoC
LO1 5m 6m
LO2 inf inf
LO3 500mm 750mm
LO4 150mm -450mm
AS1 2m 2.8m
AS2 inf inf
AS3 200mm -2m
AS4 750mm 600mm
PR2 2000m -700m
PR3 1000m 1000m
SR3 1000m -700m

 

The changes looked quite alarming, especially for LO4 and AS3, so I wrote a script to calculate the mode matching between the LO and AS beams called AS_LO_ModeMatching.ipynb and pushed it into the repo. In the notebook a bright AS beam is created by creating a small asymmetry between the arms of ~ 0.003 degrees (~10pm). Amplitude detectors were put at the input ports of the BHD BS to calculate the fields in the AS and LO beams. In particular TEM00, TEM02 and TEM20 were measured for each beam.

The calculation shows that with the old RoCs the mode matching between the LO and AS beams is 99% while for the new RoCs it is ~ 50%.

 

  16767   Fri Apr 8 16:03:58 2022 ranaUpdateElectronicsRFSoC 2x2 board -- setup for remote work & BALUN saga

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.

 

  16769   Mon Apr 11 11:00:30 2022 JancarloUpdateVACC1VAC Reboot and Nitrogen tanks

[Paco, JC, Ian, Jordan, Chub]

Checking in the morning, I walked over to the Nitrogen tanks to check the levels. Noticed one tank was empty, so I swapped it out. Chub came over to check the levels and to take note of how many tanks were left available for usage (None). Chub continued to put in a work order for a set of full Nitrogen tanks. We should be set on Nitrogen until Thursday this week (4/14/22).

As for C1VAC, this morning, Paco and I attempted to open the PSL shutter, but the interlock system was tripped so we didn't get any light into the IFO. We traced the issue down to C1VAC being unresponsive. We discussed this may have interlocked as a result of the Nitrogen tanks running out, but we do not believe this was the issue since we would have recieved an email. We tried troubleshooting as much as possible avoiding a reboot, but were unable to solve the issue. In response, we ran the idea of a reboot across Jordan and Ian, where everyone was in agreement, and fixed the system. Restarting c1vac seems to have closed V4, but this didn't cause any issues with the current state of the vacuum system.

After opening the PSL shutter again, we see the laser down the IFO, so we resume alignment work

  16772   Tue Apr 12 09:05:21 2022 JordanUpdateVACNew Pressure Gauge Install/Pump Spool Vent

Today, Tega and I would like to vent the pump spool an dinstall the new FRG-400 Agilent Pressure Gauges (per elog 15703). The attached picture shows the volume needed to be vented highlighted in red, and the gauges that need to be replaced/removed (purple dot next to the name).

The vent plan is as follows:

Open RV2

Open VM3

Open V7

Open V4

Shut down TP2

Install new gauges

Will add to post with updates post vent.

Attachment 1: Screenshot_2022-04-12_08-42-33.png
Screenshot_2022-04-12_08-42-33.png
Attachment 2: 81CB0936-1B19-4722-8A32-C3DC1D1FBC21.heic
Attachment 3: 2262ECEF-6200-4E95-8E32-C83CB9EB4F17.heic
Attachment 4: B5712B34-ECF6-43BE-BCB2-38CD775CF653.heic
Attachment 5: BEE14A07-976A-45C2-82A0-1774D377941E.heic
Attachment 6: 84557D6E-6AAE-47CF-A3AD-1DF329FEB550.heic
ELOG V3.1.3-