Preliminary RTD calculations are shown below, given an input of 10 V and desiring a few mA of current. It looks like R_ref should be at least 1 kOhm (refer to plots/circuit below), keeping in mind we need to have <10 V input for the ADC.

RP: The Red Pitaya Software was updated to OS 2.00. All examples on the RP website should run without issue.

Below are a basic diagram of what the RTD measurement circuit logically looks like and an example schematic of the actual wiring. The schematic wiring will be placed internally into a chassis, connected to the RTDs via DB25 cable.

The custom front and rear panels for the RTD readout chassis arrived last Friday. I installed them in the chassis frame to check their fit. They fit very well, so all that now remains is to complete the internal wiring and test the connections.

The chassis panel designs are archived to LIGO-D2300452 and LIGO-D2300453.

Below is the current state of the RTD readout chassis wiring. Initial continuity tests seem good, will run through one more time to confirm.

I performed another continuity test on the RTD chassis wiring, and everything seems to be set up correctly. The chassis should be ready for installation.

After updating the wiring in the RTD Chassis, a signal is now seen at each ADC input. However, there seems to be a discrepancy between the voltages I measured out with the multimeter (see below). Next steps include:

• Finish final debugging
• Calibrate ADC inputs with known voltage source (likely to use DAC).

Voltage Readings:

RTD 1: 0.576 V

RTD 2: 0.578 V

RTD 3: 0.598 V

RTD 4: 0.563 V

RTD 5: 0.477 V

RTD 6: 0.463 V

RTD 7: 0.456 V

RTD 8: 0.491 V

Reference Resistor: 5.463 V

Total Voltage: 9.665 V

After further modification of the RTD readout chassis (i.e. adding resistors, placing reference resistor in front of RTDs), here are the following direct measurements:

RTD 1: 0.484 V

RTD 2: 0.486 V

RTD 3: 0.503 V

RTD 4: 0.474 V

RTD 5: 0.495 V

RTD 6: 0.483 V

RTD 7: 0.476 V

RTD 8: 0.510 V

Reference: 5.847 V

Here are the Cymac signal readings:

RTD 1: 74

RTD 2: 67

RTD 3: 73

RTD 4: 45

RTD 5: 82

RTD 6: 75

RTD 7: 70

RTD 8: 71

Reference: 884

The one (possible) discrepancy here is the readout for RTD 4 via Cymac, since it's signal reading is ~30 counts lower than the others. I do not believe this is a wiring issue due to the direct measurements taken.

Today the FROSTI RTD readout chassis underwent a redesign:

Instead of the original ratiometric method, which involved wiring the FROSTI RTDs in series, each element is individually powered by separate excitations. Each element additionally possesses its own reference resistor of 100 Ohm. Now, if an RTD experiences an electrical short, it should not affect the measurements of the others in sequence, as it had with the original design.

The Red Pitaya ecosystem has been upgraded to OS 2.00-35, with a key feature being greater freedom in adjusting the sampling frequency for signal analysis. Before, decimation factors could only be applied if they were a power of 2 (i.e 2,4,8,16,...) up to 65536. Now, the factors can be any power of two up to 16, and any whole number greater than 16 up to 65536. Further information can be found here.

We've added two low-pass filters in hopes of reducing any potential aliasing that may be introducing additional noise into the power spectra for the RIN measurements. It still looks like the noise levels are too high. Attached below are some recent measurements taken with the FROSTI powered on and off.

I downgraded the Red Pitaya back to OS 2.00-18 due to runtime errors during measurement. Once I did this, the device appeared to work much better than it has the last few weeks. First, it appears we can actually see the cutoff of the added low-pass filters that were added in to the RIN setup. Second, there does appear to be a difference again between the FROSTI ON state versus the dark state (i.e. FROSTI OFF). A long measurement of the ADC noise floor in the current configuration still needs to be recorded, but it does appear that the recent highlighted issues with the Red Pitaya have been solved.

Attached below are updated ASD plots for the FROSTI RIN measurements. The parameters set for this are the following:

• DFT Size (N): 16384
• Sampling Frequency (F_s): 7.629 kHz
• Resolution (F_s/N): 0.93
• CH0 DC Voltage w/FROSTI ON: 113.6 mV
• CH0 DC Voltage w/FROSTI OFF: -5.7 mV
• CH1 DC Voltage w/FROSTI ON: 113.0 mV
• CH1 DC Voltage w/FROSTI OFF: -5.7 mV

Each measurement was recorded over a roughly two-day period. Before each spectrum was computed, the time-series signals were AC-coupled (i.e. the DC offset was subtracted from the data). The low-pass filters are still attached for dark and light noise measurements. ADC noise is measured with two 50-ohm terminators attached to the Red Pitaya inputs rather than the IR photodetectors.

All Sorensen power supplies are turned off. The Cymac system is down (All Chassis are down)

If you need more information or if you need to turn them back on please contact Xuesi Ma.

I conducted separate tests on the '5015' and '3010a'. When powered individually, the '5015' outputs a signal at 33.55 MHz with an amplitude of 608 mV. It draws 1 A of current from the power source. The input signal for the '3010a' is 33.54 MHz with an amplitude of 670 mV (peak-to-peak) and a 15 mV DC offset. The output signal from channel 1 is a 65.5 kHz square wave with an amplitude of 3.28 V. The '3010a' draws 0.1 A of current.

Both the '5015' and '3010a' work fine when powered separately. However, when both are powered together, the power source behaves as if there is a short circuit. The current theory is that the switch or breaker is tripping, as it has a 1 A current rating. Since the combined current demand of both devices exceeds 1 A, this may be causing the issue.

Slides for 10/16/2024 Group Meeting

1424564097.243212 2025/02/26 00:14:39 UTC Time start

12V 2A right after start all 8 elements

1424564478.079428 2025/02/26 00:21:00 UTC Time stop

12V 1.8A right before stop all 8 elements

1424564832.211584 2025/02/26 00:26:54 UTC Time start

12V 1.9A right after start all 8 elements

1424565208.359935 2025/02/26 00:33:10 UTC Time stop

12V 1.8A right before stop all 8 elements

1424565573.565066 2025/02/26 00:39:15 UTC Time start

12V 1.8A right after start all 8 elements

1424565931.242394 2025/02/26 00:45:13 UTC Time stop

12V 1.7A right before stop all 8 elements

1424566292.67104 2025/02/26 00:51:14 UTC Time start

12V 1.8A right after start all 8 elements

1424566648.619952 2025/02/26 00:57:10 UTC Time stop

12V 1.7A right before stop all 8 elements

1424566996.312246 2025/02/26 01:02:58 UTC Time start

12V 1.8A right after start all 8 elements

1424567381.748943 2025/02/26 01:09:23 UTC Time stop

12V 1.7A right before stop all 8 elements

1424567756.528736 2025/02/26 01:15:38 UTC Time start

12V 1.7A right after start all 8 elements

0.2A right before start

spikes!?

1424643001.864687 2025/02/26 22:09:43 UTC

change c_0(VEXC0 & VCXC0) to 2V (why is it on 5V ?)

2025/02/26 22:18:51 UTC

Main chamber pressure:5.92e-9

RGA chamber pressure:1.98e-9

1424650528.240947 2025/02/27 00:15:10 UTC Time start (increase voltage)

24V 2.1A right after start all 8 elements

disconnect and reconnect (exc 1-4)(out 9-12) & (exc 5-8)(out 13-16)

2025/02/27 19:34:26 UTC

Main chamber pressure:1.34e-8

RGA chamber pressure:4.33e-9

Main chamber temp: 29

RGA chamber temp:29

2025/02/28 18:02:29 UTC

Main chamber pressure:1.05e-8

RGA chamber pressure:3.53e-9

Main chamber temp: 29

RGA chamber temp:30

1424801097.374902 2025/02/28 18:04:39 UTC Time stop

24V 1.8A right before stop all 8 elements

0.1A right after stop

1424827460.71372 2025/03/01 01:24:02 UTC Time start

24V 2.9A right after start all 8 elements

0.1A right before start

2025/03/01 01:25:34 UTC

Main chamber pressure:5.98e-9

RGA chamber pressure:2.06e-9

Main chamber temp:27

RGA chamber temp:27

2025/03/03 20:28:03 UTC

Main chamber pressure:7.8e-9

RGA chamber pressure:2.64e-9

Main chamber temp:27

RGA chamber temp:27

To access and control the Red Pitaya using Python locally on a machine within the local network, one should follow these steps:

1. Start the SCPI server. This is achieved by first log onto the Red Piatay page

   rp-xxxxxx.local/ 

2. Go to Development >> SCPI server and turn the server on. (Note : The server is currently running)
3. Communication with Red Piataya is done through PyVista, install PyVista with:

    sudo pip3 install pyvisa pyvisa-py 

   This has been installed on Chimay. Ensure that you have pip3 install, if not, you can install it using:

    sudo apt-install python3 pip 

4. To start talking to the RedPitaya, ensure you have the scipt

    redpitaya_scpi.py 

   in your local folder. This is the standard class that you will import to your code to establish connection with the Red Pitaya. This code can be found in directory

    ~/RedPiatya 
    or this link
   

We noticed that the RTD temperature readings given on the Cymac were off, and traced the issue to miscalibration in the relationship between the resistance and temperature of each RTD (Callendar-Van Dusen eqn). Below is the table of values inferred from independent measurements of temperature and resistance to rectify this problem. This data was then fitted to better determine the coefficients present in the temperature-resistance relation:

       R_0 (ohm)   Alpha    Beta

RTD 0   80.8674   0.001315   4.273e-6

RTD 1   79.5704   0.001887   3.7873e-6

RTD 2   81.7334   0.002014   2.1724e-6

RTD 3   74.3060   0.003677   3.6022e-8

RTD 4   81.1350   0.001761   2.3598e-6

RTD 5   77.9610   0.002423   -7.5192e-7

RTD 6   78.7980   0.001373   6.2909e-6

RTD 7   83.8616   0.001890   3.3529e-6

       R_0 (ohm)   Alpha (1/C)

RTD 0   79.3962   0.002031

RTD 1   78.2874   0.002530

RTD 2   80.9775   0.002381

RTD 3   74.2947   0.003684

RTD 4   80.3199   0.002157

RTD 5   78.2106   0.002297

RTD 6   76.6825   0.002438

RTD 7   82.6645   0.002458

Measurements taken can be found here. An uncertainty of 1 C was assumed for temperature.

Another re-fit, but this time the quadratic coefficient (beta) is set to 1.003e-6:

       R_0 (ohm)   Alpha (1/C)

RTD 0   79.7386   0.001863

RTD 1   78.6248   0.002359

RTD 2   81.3254   0.002211

RTD 3   74.6127   0.003509

RTD 4   80.6652   0.001988

RTD 5   78.5450   0.002127

RTD 6   77.0144   0.002268

RTD 7   83.0204   0.002288

Using the data taken during the FROSTI testing at Caltech, I attempted to find a better calibration of the RTD sensors, given our past issues with inaccurate readings. The fit parameters, alpha and beta, are still all different from the initial values given to us by Fralock (alpha = .003, beta = 1.003e-6, R_0 was not given), but the true values will differ based on factors such as part geometry.

I set up the new Windows 10 laptop (pictured below), which arrived yesterday. This laptop is intended to be used for running lightweight Windows-only programs, such as the Thorlabs beam profiler software or the SRS RGA client. However, none of that software is installed yet.

Configuration details

As usual, the computer is configured with one shared account (username: controls) and the standard password. Note that it is connected to the campus wifi (UCR-SECURE).

If a connection to the lab's local network is required, then the laptop must be connected by an Ethernet cable to the switch in the top of the server rack.

The Linux workstation (ws2) that used to sit on the blue workbench (now inside the cleanroom) has been mounted on a mobile cart, as pictured below. This is intended to be a clean cart that will be housed inside the cleanroom.

The cart is currently dirty and will need to be throughly wiped down (along with the computer monitor and peripherals) prior to being moved into the cleanroom. Once the cleaned cart has been moved inside, it should never be brought back outside the cleanroom and should never be touched with ungloved hands.

I also upgraded the OS to Debian 11.6 and upgraded the CDS workstation tools.

The display resolution of the logrus has been 1064x768 and has been the only option, which is not great. While remote access to logrus using rdesktop allows rendering a virtual display of user's chosen resolution, it is not fast when using graphic-intensive program. NoMachine allows user to take over and control the machine remotely and thus appears as the same machine. However, NoMachine cannot render a virtual display like rdesktop. This has been limiting the resolution of using logrus via NoMachine.

On Friday, I found that even though we had NVIDIA Quadro P600 graphic card installed, we were not actually using it. The monitor has been connecting to the the integrated VGA display connector. This uses Microsoft Basic Display Adapter which limits the the resolution. Today I got a HDMI to Mini-display cable to connector the monitor to the Nvidia graphic card. Then in Display settings, go to Graphic settings, then enable Hardware-accelerated GPU scheduling. After restarting the machine, the machine recognised the Display 2using the Nvidia Quadro P600. In multiple displays field, selected "Show only on 2" and remove the VGA connection to the monitor. Logrus is now set at Nvidia Qadro P600 native display resolution of 1920x1080. This is now also the display resolution in NoMachine.

[Jon, Pooyan]

Moved Chimay from the server rack in Physics 1119 to a new rack in Physics 1129. It is connected to the switch in that rack and has the same ip address as before.

All services are up and running.

It appears that JupyterHub creates some processes whenever a user connects to an instance of it, but in some cases does not stop those processes after the user is not using that instance. This results in having lots of running idle processes, each using a small bit of the resources. Those processes are killed now as a result of rebooting. It might be a good idea to manually restart JupyterHub (or the whole machine) every few months to avoid this.

[Jon, Pooyan, Tyler]

A few computer machine changes have been made. 

• Logrus moved from 1119 to 1129. It is up and running with the same IP address as before. 
• A new Windows machine (host name: spica, IP:192.168.1.14) is installed in the 1119 server rack. It is connected to the RGA scanner with the serial port and is specifically used for that purpose. 
  • Update: The machine was off on 6/25, although it was left on 6/24. We think that it might have been because of Windows' default setting to suspend/hibernate the machine after idleness. To resolve this, I used  "powercfg /change" command to set all the following parameters equal to zero. The machine is still running on 6/26. 

    monitor-timeout-ac
    monitor-timeout-dc
    disk-timeout-ac
    disk-timeout-dc
    standby-timeout-ac
    standby-timeout-dc
    hibernate-timeout-ac
    hibernate-timeout-dc

• A new Debian machine (hostname: megatron, IP:192.168.1.16) is installed in the 1129 server rack. This machine is intended to be used for FEA/simulation work. A new 2TB WD Green SSD is used as its main disk drive. 

   At the moment, “controls” is the only user, and there are no apps/libraries installed on the machine.

  • Update: Jon installed LIGO cds-workstation tools and MiniConda on 6/26. 
  • Update: Pooyan and Liu set the following conda environments:
    • Env named “finesse” with Python 3.12.3 and Finesse version 3.0a24 installed. Finesse was installed via the source code. The subdirectory “/home/controls/packages” is used to store the package sourcecodes.
    • Env named “fenicsx” with the same version of Python and Finesse as the previous env, with the latest version of FEniCSx (0.8) and the test-mass-thermal-state installed.  

Set-up of the first CDS workstation for 1129, ws3, is complete and the machine is ready for use. The login credentials are the same as the other lab machines.

All that now remains is to install a permanent cable tray for running the new Ethernet cables between the electronics rack and bench (they are currently dangling from the suspended lights).

Installed a Synology NAS server (Synology RackStation RS1221) in lab room 1129, with host name “scribe” and ip “192.168.1.17”. It is mounted on the rack and each of its 8 storage bays has a 2TB SSD disk. It will be used to set up automated backups of all the lab machines (e.g., chimay, logrus, megatron).

One shared storage is set on it with SHR-2 as its RAID type. It can tolerate the failure of two disks and has 10.4TB of total capacity. 

We can use both rsync and dd to create backups of the system. A suggested backup schedule could be daily rsync backups and bi-weekly disk snapshots using dd. 

Today I installed the second desktop workstation in 1129. The new machine is an Intel NUC13ANHi5, with a 12-Core Intel i5-1340P CPU, 32GB DDR4 RAM, and a 1TB SSD.

I loaded it with a fresh installation of Debian 12 and installed the LIGO CDS workstation (control room) tools. It is assigned the hostname ws4 and and the static IP address 192.168.1.19 on the local lab network. Like the other CDS workstations, there is just one user account accessible with the usual credentials.

The machine is fully set up and ready for use.

One ongoing work is to make all lab machines automatically backed-up on Scribe on a daily basis. The updates should be boatable and stored for some time (potentially a few weeks) on Scribe. Making whole disk images has already been tried for some of the machines with no problems. (e.g., Cymac and WorkStations)

The same thing can not be done with Chimay though, as it currently has one huge RAID-controlled volume that stores all the information (OS, home directories, and NDS-downloaded data). Creating daily full disk images of such a system is not practical. 

Here is the plan we came up with to overcome this issue:

1. Create one full disk image of Chimay and store it on Scribe (it was already done)
2. Move the nds-downloaded raw data temporarily to Scribe and remove it from Chimay
3. Make another full disk image of Chimay
4. Burn this image to a single disk and boot chimay with it

5. Restore the rest of Chimay disks and move the NDS data back

    

On the weekend (Sat and Sun 9/7-8) I tried to execute these steps. There wasn't enough free space left on Scribe to move all the NDS data to it, so I stored part of this data temporarily on WS4. Then I also checked storage-consuming directories and, in one case, removed some non-important stored files. As there was no free space left on Scribe to execute step no. 3, I initiated storing the image on WS3. Unfortunately, a couple of different trials of the image-creation process failed as there was not enough free space on WS3 to accommodate Chiamy image as well. I was not able to reduce the image size such that it can be stored on WS3. 

These are the options left for us to get this work done. 

1. Distribute the NDS files between different machines to make enough free space on Scribe for the image and then follow the previous plan
2. Shrink the Chimay drive size, create the image and then follow the previous plan
3. Temporarily transfer some services to Megatrone (Network gateway, Wiki, elog) and recreate chimay and its services from scratch

• Hosted Lukes model on Chimay. It's available at https://richardsonlab.ucr.edu/real-time-frosti
• The sourcecode is at Github. It is clones at /var/www/html/real-time-frosti, and this is the block added to nginx config file at /etc/nginx/sites-available/default :
  
  location /real-time-frosti {

root /var/www/html;
index index.html index.htm index.php;
}
• Also added this line to the crontab, so the code will be checked for updated from the sourcecode every five minutes. 
  
  */5 * * * * cd /var/www/html/real-time-frosti/ && git pull 
  
  
• TODO: Move the sourcecode from Github to git.ligo.org, and make the repository public. 

Port 80 is kept closed by default. This might be causing the certbot auto-renewal cronjob to fail. Therefore we must renew the certificate manually.

Step 1: Open port 80. (This is needed as the certificate renewal process runs some tests which requires client communication over port 80)

Step 2: Run the following command

sudo certbot certonly --force-renew -d richardsonlab.ucr.edu

Step 3: Confirm the certificate was renewed by running the following command

sudo certbot certificates

Jon, Cao

Today we raised the height of the shelf overhanging the cleanroom laser table by 8 inches. This was done to create more vertical clearance between the top-loading vacuum chamber and the bottom of the shelf. The added clearance should make both removing the chamber lid and inserting large parts easier.

The procedure required unmounting the shelf and removing all eight vertical support posts (1" x 1" x 18.5" pieces of 80/20 unistrut). The support posts were taken to the machine shop and cut, retapped, and cleaned (coarsely, with IPA wipes) prior to reinstallation. We took care to minimize the contamination introduced into the cleanroom, but some amount of particulate from disturbing the shelf was unavoidable.

This work is completed, and the cleanroom is now ready for final cleaning (HEPA vac, mopping, and wiping down of all surfaces including the softwalls).

Jon, Cao

In effort to try to reduce the noise level inside the cleanroom, we have dialed all four HEPA fan-filter units (FFUs) down from HIGH to MEDIUM speed. These dials can only be accessed from inside the cleanroom, by bringing in the large ladder and opening adjacent ceiling tiles.

We tested three configurations, in each case with all the FFUs on either HIGH (initial state), MEDIUM, or LOW. We measured the ambient noise in each configuration.

Going from HIGH to MEDIUM yields the largest improvement, reducing the ambient sound intensity by 6 dB (i.e., by a factor of 4, corresponding to a ~35% reduction in perceived volume).

An additional 3 dB of noise reduction can be achieved by further reducing the fan speeds to LOW. However, even after allowing some extended settling time (few hours), we found the particle counts to be fluctuating right at the threshold zone for ISO Class 5. Thus we dialed the fan speeds back up to MEDIUM with the expectation that this will be sufficient for Class 5 performance.

The cleanroom now needs to be recertified with a fresh round of five-zone particle count measurements.

• pre-cleaning particle counts:
  • zone 3
  • 0.3 mu: 2494
  • 0.5 mu: 748
  • 1.0 mu 124
  • zone 4
  • 0.3 mu: 374
  • 0.5 mu: 41
  • 1.0 mu: 0
• 3:45 pm: Started wiping the surfaces(laser table,chamber, computer) inside the cleaning room.
• 4:05 pm: Finished wiped the surfaces
• 4:08 pm: Began vacuuming cleanroom floor
• 4:28 pm: Finished vacuuming cleanroom floor.
• 4:29 pm: Began mopping the cleanroom floor.
• 5:15 pm: Finished cleanroom clean.
• 6:00 pm: post-cleaning particle counts (full 5 zone measurement) attached below

cleaning cleanroom and particle count

• 12:00 pm: started particle count
  • Zone 3
    • 0.3u: 3533
    • 0.5u: 540
    • 1.0u: 166
  • Zone 4
    • 0.3u: 290
    • 0.5u: 124
    • 1.0u: 41
• 12:31 pm: Started checking the surface inside the cleanroom and began surface wipedown
• 12:50 pm: started vacuuming the floor
• 1:05 pm: Finished vacuuming floor
• 1:09 pm: Started mopping the floor
• 1:21 pm: Finished mopping the floor
• 1:22 pm: Started cleaning the baskets
• 1:25 pm: Started mopping with IPA wipes
• 1:39 pm: Finished mopping with IPA wipes
• 1:41 pm: Changed sticky floor mats
• 1:45 pm: Started particle count
  • Zone 3
    • 0.3u: 2327
    • 0.5u: 581
    • 1.0u: 207
  • Zone 4
    • 0.3u: 1662
    • 0.5u: 374
    • 1.0u: 290