• I collected data to plot a calibration with the heater. I took measurements with current and temperature (the thermocouple - thermometer) to compare with the FLIR measurements.
• I made a plot with this data and we can see how temperature vs current behaves. Note: This data I measured manually.

• Today I tried get data the heater with the black screen but doesn't looks possible have just one "energy" point straight to FLIR camera. Tyler and I tried different current and temperatures but keep very bad data. I attached a snap below.
• I attached a photo about the new setup below. The FLIR is in the most close point possible/safety with the heater. The heater is very close to the black wall but is not touch the screen so is safety.

• I noticed that these measurements have some issues with the weather on different days. We can see in the photo attached below how different the temperatures are on different days, I took the data with the same procedure every day, but we can see the differences between them.
• To Do: I will do a new data collection using FLIR and thermocouple at the same time to plot comparison between both.

• I was able to plot the first graph for a result between the six different positions on the screen, for now we can see the behavior of the heater temperature in a Gaussian graph with combination data between the six files.
• To do: Tyler gave me some ideas today to improve the plot. So I'm going to change the code to have insulation on the values for just the heater ("insulation") and I'm going to plot after this insulation data as well I'm going to get more data and compare with more data for the same position.
• I was using the data than I got last week and I shared on Elog (151) and we can see on this quote

• Today I was able to plot a graph for the isolation point on the center of the heater. I got data from six different positions on the screen (I shifted the all coordinates). I extracted the data for the center point and plot the Gaussian with this extracted data for temperature. I attached the all plots below
• Also I took a snap using the black wall and with the heater at 120.1 C (0.30 A) try to have less noise but we can see this is not very good. At this temperature, we have noise on the top and I don't understand why because the heater is not in this location. I attached a snap below.

• Today I got more data to plot the Gaussian. So I took more snaps in each position for the six different spots than we be using to have a better calibration of the FLIR collected data. I attached the new plot below. Also, I did the same plot for each region as on the Elog 167 but I have more than 20 pics because I was using a big number of data so I just attached one example below.

To access the Elog, click here.

• Also I think we have some real (non-ideal) heat diffusion by the screen and not noise like Dr. Richardson suggested. I was testing today and we can see the first pic before the start heater source turns on, the second pic is at 120.2 C (0.31A) with the heater on and the last pic is after the heater source cooled back down to room temperature. Just in the second pic, we have a strong spot on the top, so it looks like a non-ideal diffusion.

1. I was able to plot the final result with the data to the heater. I attached below the "3Combined_HighTemp_Gaussian_Plot." in this plot we can see better behavior on the Gaussian compared to the plot in ELOG 169, I was using the same data but with a different approach. On the ELOG 169, we have the center point isolated data and this new plot is the temperature more than 70 C isolated because we have a very good heater temperature distinguish do background. For the all data I got I was using a power current of 0.20A. To get the data I waited for 30 minutes until the heater became stable and after that, I started to take snaps, I took more than one snap for each one different 6 positions on the screen, and We can see the positions on ELOG 167.
2. Also I attached the calibration plot ("calibration_plot") between the measurements with the FLIR camera and thermocouple and we can see looks good if we compare the final plot.
3. For better analyses I attached a plot of the calibration line on the Gaussian plot.
4. To do: I will finish the final report.

Below is the proposed schematic for FROSTI optical testing, chosen so enough space is allotted for prototype assembly.

Steps to be taken include:

1. Reconstruct FLIR staging apparatus
2. Move test mass stand-in to cleanroom
3. Mark FLIR camera position on cleanroom optical table at correct distance
4. Run ethernet cable into cleanroom
5. Move FLIR aside to allow for more assembly space
6. Upon assembly completion, reposition FLIR onto optical table again

Tentative plan is to begin setup early next week.

The FLIR and test mass stand-in have been transferred into the cleanroom. A software test will be run as soon as we get an ethernet cable long enough to reach into the cleanroom where the camera is set up. Once this is finished, the FLIR will be moved aside for construction of the FROSTI! When completed, the camera will be placed back into position for in-air optical testing.

Some changes have been made to the FLIR readout code to help improve its functionality:

• More accurate temperature readings than before due to updates in the calculation procedure. A bug was causing one of the parameters to not update correctly; this is now fixed.
• Saved data now stored in HDF5 files rather than CSV.
• User can now enable automatic data storage by specifying a collection interval (in minutes). The choice of manually saving data is still present if desired.

Attached below are the initial results of the CIT FROSTI testing analysis.

Upon further inspection, one adjustment was made to the FROSTI profile analysis: changing the transmission value of the ZnSe viewport. It was initially assumed that the viewport possessed an AR coating, which would bring the transmission into the 90% range. Without the coating, it drops to roughly 70%. Assuming no coating, the estimated delivered power was calculated to be 11.7 W. This is consistent with the estimated power given from the Hartmann sensor analysis, thus it is believed that the viewport indeed had no coating.

After taking data for each of the individual heater elements, I imported them into python and overlayed them to produce an average temperature profile. I rotated the 7 of the elements to align with element 1's profile and averaged them out. By setting the range to 28C - 33C (this gave the best visibility of the heating pattern) it gave the profile attached.

Heating system

Wiping the heater system parts.
• 04:37 pm: Started wiping the electronic device part for the heater system (HL101 Series Digital Benchtop temperature limit control).
• 05:19 pm: Finished wiping the parts to the heater system (HL101 Series Digital Benchtop temperature limit control). I wiped the HL101 Series Digital Benchtop temperature limit control and I didn't bagged and tagged because we should install that soon.
• 05:23 pm: I putted heater electronic device inside the cleanroom without the bag. Also the electronic device is near to the vacuum chamber and the other parts to heater system.
• I attached the photo below.

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

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.