Summary

• Alex, Anchal, and I adjusted the every overall gain iin P/Y of WFS1, 2 and MC2_TRANS loop.
• We set the WFS1, 2 P/Y UGFs to be ~2-3 Hz, and the MC2_TRANS loops to have a UGF of ~0.1 Hz.

Method

From the previous results (40m/17489) and measuring the open-loop transfer function (OLTF) by broadband noise, we adjusted the overall gain in P/Y of WFS1, 2 and MC2_TRANS loop. The table represents the changed values.

We also note the overall gain of the injecting noise: WFS1_PIT 52345, WFS2_PIT 152345, MC2_TRANS_PIT 152345, WFS1_YAW 152345, WFS2_YAW 102345, and MC2_TRANS_YAW 102345. The values are used in the awggui window.

We measured the OLTF by the appropriately filtered noise. The filter we used is the same as that of the previous measurement.

Result

Attachment 1 shows the OLTF whose gain is adjusted.

Summary

• We compared the new output matrix with old one by the step response test.
• We focused on the off-diagonal components of the step response result to compare the output matrix.
• We found that the old one is relatively good to WFS1/2 and MC2_TRANS whereas the new one is useful only to WFS1.
• Also we found that the new output matrix made from the sensing matrix was not significantly better than the original one.

Purpose

Alex, Anchal, and I did the experiment to find out the better output matrix. We got the new output matrix from the step response test in 40m/17500, so we checked whether the output matrix is good or not.

Theory

We used the following method to check the output matrix. In the previous step response test, we applied the step offset to ``ExciteIn'' points, and measure the step response at ``SensOut'' points. These points are defined in Attatchment 4. From the test, we got the matrix . Thus, we derived the new output matrix  from taking the inverse of , . If the new output matrix is well derived, the matrix can diagonalize the product of  and , , where  is the identity matrix.  can be measured by the step response test from ``SensIn'' to ``SensOut.'' Therefore we checked the output matrix by measuring . We call the measured matrix  as a sensing matrix.

To evaluate that  is diagonalized, we computed the sum of the absolute values of the off-diagonal components in 

Note that each column of the matrix was normalized by its diagonal component.

We tried to find out the better output matrix as the following method. We created new output matrix  from , and did the same step response test with . Then we got the new sensing matrix . We computed the sum of the absolute values of the off-diagonal components in , . We can get the relation  if  is better than . Therefore we compared  with .

Note: If  and  have the relation , the output matrix  will get better and better.

We also did the step response test with , which is defined as the output matrix now used. Then we compare  with .

Method

Before doing each step response test, we did the following processes:

• MC WFS relief for 60 secs with closed loops,
• turn off the WFS servo,
• turn off all the filters (WFS1/2: FM3, 4, 6; MC2-TRANS: FM1, 3, 4, 6),
• change the output matrix,
• set all the gain as unity,
• adjust each step offset.

We used the python script, toggleWFSoffsets.py, for testing the step response. The script is stored in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The time appling each step offset is set as 120 secs.  are specifically the following matrix:

Note:  is different from [-0.188, -0.009, ...] in 40m/17500 because the previous calculation had a mistake.

The step response data is analyzed for making plot and calculating  and  by the python script, /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/IOO_WFS_YAW_RESPONSE_TEST_100323.ipynb. 

Result

The step response results for  are represented in Attachment 1, 2, 3, respectively. In each plot, upper left shows all the data for WFS1 (solid green), WFS2 (solid blue), and MC2_TRANS (solid brown). Also upper right, lower left, and lower right shows the result of WFS1, WFS2, and MC2_TRANS, respectively. The plots except for the upper left have the applied step offset drawed by dashed line. The three step offsets were applied in the order of WFS1 (dashed green in the upper right), WFS2 (dashed blue in the lower left), and MC2_TRANS (dashed brown in the lower right). The high-frequency components of all the plots are removed with a second-order Butterworth low-pass filter and then plotted. Dotted line and its surrounding area show the mean value for each step response or existing offset without the step offset, and its standard deviation, respectively.

We summarize each plot:

The matrix of  is written from Attachment 1:

Focusing on each column in  and the plot, only the step response for WFS1 is well diagonalized. The result of  is . Note that all the sign of the step offset in Attachment 1 is negative because we set each gain of the filter as -1.

The matrix of  is written from Attachment 2:

The output matrix  has worse normalization to WFS1 than  from comparing  with .  also gets worse value than : .

The matrix of  is written from Attachment 3:

Although  has relatively better normalization to WFS1 and 2 than , it is characterized by a large overall error.  has minimum value with relatively large uncertainty: .

Discussion

We compare each value , which is plotted in the left of Attachment 5. From the figure, we can find  and  agree within the margin of error, and  is significantly smaller than  and . Also we compare  focusing on WFS1 column shown in the right of Attachment 5.  have almost the same value, and  has slightly larger value than other. This result shows  is relatively good to WFS1/2 and MC2_TRANS whereas  is useful only to WFS1.

Alex, Anchal, and I adjusted the number of the MC2-TRANS column in the YAW output matrix. We used the same method in 40m/17504 but the amplitude of oscillator for Lock In Amplifier is increased from 1 to 4.

The corrected numbers of the column in the output matrix is as follows:

We did the step response test for the corrected output matrix. The sum of off-diagonal terms was 0.62, which is the minimum value. Attachment 1 is the step response test result. From the figure, the reduction of the sum is because the column MC2_TRANS can diagonalize better. We can find out the property from Attachment 2.

Purpose

• To adjust the components of the WFS2 column in the YAW output matrix.
• To check the value of the off-diagonal components of the WFS1 column.

Method

Alex, Anchal, and I used the same method in 40m/17504 to adjust the components of the WFS2 column. And we did the same step response test to check the value of the off-diagonal components in the YAW output matrix.

Used script & file

All the scripts & files are stored in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/ directory.

• DiagnoalizatingMethod.ipynb: for adjusting the components and replacing the new output matrix,
• toggleWFSoffsets.py: for doing the step response test,
• IOO_WFS_YAW_STEP_RESPONSE_TEST.py: for analyzing the step response result.

Result

We changed the WFS2 column as follows

We can successfully diagonalize the WFS2 column. The sum of the off-diagonal components is slightly reduced. However, WFS1 has worse diagonalization.

The same step response test should be performed on a different day to see if the results change. It is because the multiple causes could exist: the influence of the changed other columns, the long time drift, the day to day change, and so on.

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.

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.

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.

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

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

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

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

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

Progress So Far:

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

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

Some things to note:

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

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

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

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

Example: 8 MHz Square Wave from SRL signal generator.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Paco, Tomislav]

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

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

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

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

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

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

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

[Lydia,Teng]

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

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

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

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

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

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

3. use the caculated butterfly channel.

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

Also deleted the ~50GB error files from ldas to prevent rsync from copying them to nodus again. With the new update to GWsumm, there are new error messages that initially didn't seem to affect the summary pages functionality, but in the extreme case can populated the error files the repeated warnings on the form "Loading: FrSerData", "Loading: FrSerData::n4294967295", "Loading: FrSummary","Loading: FrSerDataLoading: FrSerData" and many more combinations until we get file sizes of the order of ~50GB. So I have updated the checkstatus script to parse the error files and strip out the majority of these error messages. Work is ongoing to get them all.

In light of these large files generation, I decided to look in the summary pages folder to see if there are other large files that we need to keep track of and it turns there are indeed a collection of files in the archive folder that bloats the summary pages on ldas to ~1TB. Luckily these are not synced to nodus so no problem here. However, since the beginning of the year, the archive folders that hold data used for each day's computation have not been cleared. We have a script for doing this but it has not been run for a while now and it only delete archive files for a specific month which is hardcoded to two months from the date the file is run. I have modified the code to allow archive deletion for a range of months so we can clear data from Jan to July. 

[paco]

This morning, I spent some time restoring the jupyter notebook server running in allegra. This server was first set up by Anchal to be able to use the latest nds python API tools which is handy for the calibration stuff. The process to restore the environment was to run "source ~/bashrc.d/*" to restore some of the aliases, variables, paths, etc... that made the nds server work. I then ran ssh -N -f -L localhost:8888:localhost:8888 controls@allegra from pianosa and carry on with the experiment.

[paco, hang, tega]

We started a notebook under /users/paco/20210906_XARM_Cal/XARM_Cal.ipynb on which the first part was doing the following;

• Set up list of excitations for C1:LSC-XARM_EXC (for example three sine waveforms) using awg.py
• Make sure the arm is locked
• Read a reference time trace of the C1:LSC-XARM_IN2 channel for some duration
• Start excitations (one by one at the moment, ramptime ~ 3 seconds, same duration as above)
• Get data for C1:LSC-XARM_IN2 for an equal duration (raw data in Attachment #1)
• Generate the excitation sine and cosine waveforms using numpy and demodulate the raw timeseries using a 4th order lowpass filter with fc ~ 10 Hz
• Estimate the correct demod phase by computing arctan(Q / I) and rerunning the demodulation to dump the information into the I quadrature (Attachment #2).
• Plot the estimated ASD of all the quadratures (Attachment #3)

[paco, hang, tega]

Estimation of open loop gain:

• Grab data from the C1:LSC-XARM_IN1 and C1:LSC-XARM_IN2 test points
• Infer excitation from their differnce, i.e. C1:LSC-XARM_EXC = C1:LSC-XARM_IN2 - C1:LSC-XARM_IN1
• Compute the open loop gain as follows : G(f) = csd(EXC,IN1)/csd(EXC,IN2), where csd computes the cross spectra density of the input arguments
• For the uncertainty in G, dG, we repeat steps (1) to (3) with & without signal injection in the C1:LSC-XARM_EXC channel. In the absence of signal injection, the signal in C1:LSC-XARM_IN2 is of the form: Y_ref = Noise/(1-G), whereas with nonzero signal injection, the signal in C1:LSC-XARM_IN2 has the form: Y_cal = EXC/(1-G) + Noise/(1-G), so their ratio, Y_cal/Y_ref = EXC/Noise, gives the SNR, which we can then invert to give the uncertainty in our estimation of G, i.e dG = Y_ref/Y_cal.
• For the excitation at 53 Hz, our measurtement for the open loop gain comes out to about 5 dB whiich is consistent with previous measurement.
• We seem to have an SNR in excess of 100 at measurement time of 35 seconds and 1 count of amplitude which gives a relative uncertainty of G of 0.1%
• The analysis details are ongoing. Feedback is welcome.

I finally got the modbus part working on chiara, so we can now view the temperature data on any machine on the martian network, see Attachment 1. 

I also updated the entries on /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini, as suggested by Koji, to include the SensorGatway temperature channels, but I still don't see their EPICs channels on https://ldvw.ligo.caltech.edu/ldvw/view. This means the channels are not available via nds so I think the temperature data is not being to be written to frame files on framebuilder but I am not sure what this entails, since I assumed C0EDCU.ini is the framebuilder daq channel list.

When the EPICs channels are available via nds, we should be able to display the temperature data on the summary pages.

Anchal mentioned it would be good to put more details about how I arrived at the values needed to configure the modbus drive for the temperature sensor, since this information is not in the manual and is hard to find on the internet, so here is a breakdown.

So the generic format is:

drvAsynIPPortConfigure("<TCP_PORT_NAME>","<UNIT_IP_ADDRESS>:502",0,0,1)
modbusInterposeConfig("<TCP_PORT_NAME>",0,5000,0)
drvModbusAsynConfigure("<PORT_NAME>","<TCP_PORT_NAME>",<slaveAddress>,<modbusFunction>,<modbusStartAddress>,<modbusLength>,<dataType>,<pollMsec>,<plcType>)

which in our case become:

drvAsynIPPortConfigure("c1pemxendtemp","192.168.113.240:502",0,0,1)
modbusInterposeConfig("c1pemxendtemp",0,5000,0)
drvModbusAsynConfigure("C1PEMXENDTEMP","c1pemxendtemp",0,4,199,2,0,1000,"ServerCheck")

As can be seen, the parameters of the first two functions "drvAsynIPPortConfigure" and "modbusInterposeConfig" are straight forward, so we restrict our discussion to the case of third function "drvModbusAsynConfigure". Well, after hours of trolling the internet, I was able to piece together a coherent picture of what needs doing and I have summarised them in the table below.

drvModbusAsynConfigure

Once the asyn IP or serial port driver has been created, and the modbusInterpose driver has been configured, a modbus port driver is created with the following command:

drvModbusAsynConfigure(portName,                # used by channel definitions in .db file to reference this unit)
                       tcpPortName,             # reference to portName created with drvAsynIPPortConfigure command
                       slaveAddress,            # 
                       modbusFunction,          # 
                       modbusStartAddress,      # 
                       modbusLength,            # length in dataType units
                       dataType,                # 
                       pollMsec,                # how frequently to request a value in [ms]
                       plcType);                #

Useful links

https://nodus.ligo.caltech.edu:8081/40m/16214

https://nodus.ligo.caltech.edu:8081/40m/16269

https://nodus.ligo.caltech.edu:8081/40m/16270

https://nodus.ligo.caltech.edu:8081/40m/16274

http://manuals.serverscheck.com/InfraSensing_Sensors_Platform.pdf

http://manuals.serverscheck.com/InfraSensing_Modbus_manualv5.pdf

https://community.serverscheck.com/discussion/comment/7419#Comment_7419

https://wiki-40m.ligo.caltech.edu/CDS/SlowControls

https://www.slac.stanford.edu/grp/ssrl/spear/epics/site/modbus/modbusDoc.html#Creating_a_modbus_port_driver

https://github.com/riptideio/pymodbus

https://en.wikipedia.org/wiki/Modbus

https://deltamotion.com/support/webhelp/rmctools/Communications/Ethernet/Supported_Protocols/Ethernet_Modbus_TCP.htm

[Tega, Anchal, Paco]

After talking to Anchal, it was made clear that chiara is not the place to host the modbus service for the temperature sensors. The obvious machine is c1pem, but the startup cmd script loads c object files and it is not clear how easy it would integrate the modbus functionality since we can only login via telnet, so we decided to instead host the service on c1susaux. We also modified the /etc/motd file on c1susaucx which displays the welcome message during login to inform the user that this machine hosts the modbus service for the temperature sensor. Anchal plans to also document this information on the temperature sensor wiki at some point in the future when the page is updated to include what has been learnt so far.

We might also consider updating the database file to a more modern way of reading the temperature sensor data using FLOAT32_LE which is available on EPICs version 3.14 and above, instead of the current method which works but leaves the reader bemused by the bitwise operations that convert the two 16 bits words (A and B) to IEEE-754 32-bit float, via 

field(CALC, "(A&D?(A&C?-1:1):0)*((G|A&E)*J+B)*2^((A&D)/G-F)")

where 

   field(INPA, "$HiWord")
   field(INPB, "$LoWord")
   field(INPC, "0x8000")   # Hi word, sign bit
   field(INPD, "0x7F80")   # Hi word, exponent mask
   field(INPE, "0x00FF")   # Hi word, mantissa mask (incl hidden bit)
   field(INPF, "150")      # Exponent offset plus 23-bit mantissa shift
   field(INPG, "0x0080")   # Mantissa hidden bit
   field(INPJ, "65536")    # Hi/Lo mantissa ratio
   field(CALC, "(A&D?(A&C?-1:1):0)*((G|A&E)*J+B)*2^((A&D)/G-F)")
   field(PREC, "4")

as opposed to the more modern form

field(INP,"@asyn($(PORT) $(OFFSET))FLOAT32_LE")

We can now view the minute trend of the temperature sensors under the PEM tab of the summary pages. See attachment 1 for an example of today's temperature readings. 

Running update of Sat Amp modification work, which involves the following procedure (x8) per unit:

1. Replace R20 & R24 with 4.99K ohms, R23 with 499 ohms, and remove C16.
2. (Testing) Connect LEDDrive output to GND and check that
   • TP4 is ~ 5V
   •  TP5-8 ~ 0V. 
3. Install 40m Satellite to Flange Adapter (D2100148-v1)

[Koji, Tega]

Decided to do a quick check of the remaining Sat Amp units before component replacement to identify any unit with defective LED circuits. Managed to examine 5 out of 10 units, so still have 5 units remaining. Also installed the photodiode bias voltage jumper (JP1) on all the units processed so far.

Defective unit with updated resistors and capacitors in the previous elog

Debugging complete.

All units now have the correct TP4 voltage reading needed to drive a nominal current of 35 mA through to OSEM LED. The next step is to go ahead and replace the components and test afterward that everything is OK.

Trying to finish 2 more Sat Amp units so that we have the 7 units needed for the X-arm install. 

S2100736 - All good

S2100737 - This unit presented with an issue on the PD1 circuit of channel 1-4 PCB where the voltage reading on TP6, TP7 and TP8 are -15.1V,  -14.2V, and +14.7V respectively, instead of ~0V.  The unit also has an issue on the PD2 circuit of channel 1-4 PCB because the voltage reading on TP7 and TP8 are  -14.2V, and +14.25V respectively, instead of ~0V.

[Tega, Koji]

(S2100737) - Debugging showed that the opamp, AD822ARZ, for PD2 circuit was not working as expected so we replaced with a spare and this fixed the problem. Somehow, the PD1 circuit no longer presents any issues, so everything is now fine with the unit.

(S2100741) - All good.

[S2100738, S2100745, S2100751] Completed three more Sat Amp units modification with seven remaining.

Modifications and testing of SatAmp units COMPLETE. Attachments 1 & 2 show all 19 units, one installed unit and the remaining 18 units are stacked and ready for install. Detailed notes of the modification for each unit are presented in the summary document in the dcc.

[Ian,Tega]

Today we continued working on setting up the 6 degrees of freedom model for testing the suspension which we copied over from  "/cvs/cds/rtcds/userapps/release/sus/c1/models/c1sup.mdl" to c1sp2.mdl in the same folder. We then changed the host from c1lsc to c1sus2, changed cpu # from 7 to 3 bcos c1sus2 has 6 cores. Then ran the following commands to build and install the model on c1sus2:

$ ssh c1sus2

$ rtcds make c1sp2

$ rtcds install c1sp2

where we encountered the following installation error:

It seems that changing the model name and host did not change the node allocation, so will remove the previous entries in testpoint.par to see if that helps. After deleting the following lines

[C-node62]
hostname=c1lsc
system=c1sup

from the file "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par", the installation went fine and the above entries were replaced by 

[C-node62]
hostname=c1sus2
system=c1sp2

BTW, I now believe the reason we had the node conflict earlier was bcos both models still had the same value of  dcuid=62, so I think changing this value in our model file would be a better solution. Work is ongoing.

[Tega, Ian]

TODO

1. Investigate cross-coupling btw the various degrees of freedom (dof) - turn on noise for each dof in the plant model and measure the transfer function of the other dofs.

2. Get a closed-loop transfer function using noise injection and give a detailed outline of the procedure in elog - IN1/IN2 for each TM_RESP filter while the others are turned off.

3. Derive analytic model of the closed-loop transfer functions for comparison.

4. Adapt control filters to fit optimized analytical solutions.

The new SUS screen can be reached via sitemap -> IFO SUS button -> NEW ETMX dropdown menu link. Please use and provide feedback. Not sure exactly if we need/want the display screens after the IOP model on the right of the medm screen. I have not been able to locate the corresponding channels but did not want to remove them until I was sure that we don't plan to add these features to our screens. When all bugs have been ironed out, we can use appropriate macro substitution for the other optics.

The next feature to add is the BLRMS to the coil and PD channels. I plan to combine the PEM BLRMS medm implementation with the sus_single_BLRMS model block (located in  /opt/rtcds/userapps/release/cds/c1/models). This way we use the latest BLRMS block in "/opt/rtcds/userapps/release/cds/common/models/BLRMS.mdl" whilst also leveraging the previous work done on the sus_single_BLRMS model, which neatly fits into our current SUS model.

Work on the medm screen for SUS RMS monitor is ongoing. The next step would be to incorporate this into the SUS medm screen, add the BLRMS model to the SUS controller model, recompile, check that the channels are being correctly addressed, then load the appropriate bandpass and lowpass filters.  

Turns out the BLRMS monitoring channels for MC1, MC2, MC3, ITMY and SRM already exist in c1pem. So I modified the new SUS screen to display the BLRMS info for the aforementioned optics. Next step is to add the BLRMS monitor for PRM, ITMX, ETMX and ETMY. This would require extending the number of inputs for the "SUS" block in c1pem to accomodate the additional inputs from the remaining optics.

[temperature sensor]

git repo: https://git.ligo.org/40m/tempsensor.git

todo

Update the temp sensor channels to fit with cds format, ie. "C1:PEM-TEMP_EX", "C1:PEM-TEMP_EY", "C1:PEM-TEMP_BS"

- Use FLOAT32_LE data format for the database file (/cvs/cds/caltech/target/c1pem1/tempsensor/C1PEMaux.db) to create the new channels.

- Keep the old datadase code and channels so we can compare with new temp channels afterwards. Also we need a 1-month overlap b4 deleting the old channels.

[sus medm screen]

git repo: https://git.ligo.org/40m/susmedmscreen.git

todo (from talk with Koji)

- Link stateword display to open "C1CDS_FE_STATUS.adl"

- Damp filter and Lock filter buttons should open a 3x1 filter screen so that the 6 filters are opened by 2 buttons compared to the old screen that has 3 buttons connected to 2X1 filter screen

- Make the LOCKIN signla modulation flow diagramlook more like the old 40m screen since that is a better layout

- Move load coefficient button to top of sus medm screen (beside stateword)

- The rectangular red outline around the oplev display is confusing and needs to be modified for clarity

- COMM tag block should not be 3D as this suggests it is a button. Make it flat and change tag name to indicate individual watchdog control as this better reflect its functionality. Rename current watchdog switch to watchdog master is it does what the 5 COMM switches do at once.

- Macro pass need to be better documented so that when we call the sus screens from locations other than sitemap, we should know what macro variables to pass in, like DCU_ID etc.

- Edit sitemap.adl to point only to the new screens. Then create a button on the new screen that points to the old screen. This way, we can still access the old screen without clogging sitemap.

- Move the new screen location to a subfolder of where the current sus screens reside, /opt/rtcds/userapps/trunk/sus/c1/medm/templates

- Rename the overview screen (SUS_CUST_HSSS_OVERVIEW.adl) to use the SUS_SINGLE nomenclature, i.e. SUS_SINGLE_OVERVIEW.adl

- Keep an eye of the cpu usage of c1pem as we add BLRMS block for other optics. 

[Temperature sensor]

Added new temp EPICs channels to database file (/cvs/cds/caltech/target/c1pem1/tempsensor/C1PEMaux.db)

Added new temp EPICs channels to slow channels ini file (/opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini)

[SUS medm screen]

Moved new SUS screen to location : /opt/rtcds/userapps/trunk/sus/c1/medm/templates/NEW_SUS_SCREENS

Place button on the new screen to link to the old screen and replace old screens link on sitemap.

Fixed Load Coefficient button location issue

Fixed LOCKIN flow diagram issue

Fixed watchdog labelling issue

Linked STATE WORD block to FrontEnd STATUS screen

Replaced the 2x1 pit/yaw filter screens for LOCK and DAMP fliters with 3x1 LPY filter screen

*Need some more time to figure out the OPTLEV red indicator

Seen. Thanks.

Red Arrow: The channel was labeled incorrectly as INMON instead of OUTPUT

Green Arrow: OK, I will create a custom medm screen for this.

Blue arrow: Hmm, OK I will look into this. Doing this work remotely is a pain as the medm response is quite slow for poking around.

Orange circle: OK, I'll move this to the left side of the line.

Note to self: I also noticed another error on the side (LPYS blue box just b4 the sum). The channel is pointing to YAW instead of the side, so needs to be fixed as well.

Started working on this. First created a git repo for tracking https://git.ligo.org/40m/susaux.git

I have looked through the folder to see what needs doing and I think I know what needs to be done for the final case by just following the same pattern for the other optics, which I am listing below

- Create database file for the BHD optics, say C1_SUS-AUX_LO1.db by copying another optic database file say C1_SUS-AUX_SRM. Then replace the optic name.

- Insert a new line "C1:SUS-LO1_LATCH_OFF" in the file autoBurt_watchdogs.req

- Populate the file autoBurt.req with the appropriate channels for LO1

- Populate the file C1SUSaux_post.sh with the corresponding commands for LO1

- Add the line dbLoadDatabase("/cvs/cds/caltech/target/c1susaux/C1_SUS-AUX_LO1.db") to the file C1SUSaux.cmd

For the temporary watchdog, we comment everything I have just talked about, and do only what come next.

My question is the following:

I understand that we need to use the OUT16 slow channel as a temporary watchdog since we don't currently have access to the slow channels bcos the Acromag units have not been installed. My guess from Koji's instructions is that we need to update the channels in the last two fields "INPA" and "INPB" below

record(calc,"C1:SUS-LO1_UL_CALC")
{
        field(DESC,"ANDs Enable with Watchdog")
        field(SCAN,"1 second")
        field(PHAS,"1")
        field(PREC,"2")
        field(HOPR,"40")
        field(LOPR,"-40")
        field(CALC,"A&B")
        field(INPA,"C1:SUS-LO1_UL_COMM  PP  NMS")
        field(INPB,"C1:SUS-LO1_LATCH_OFF  PP  MS")
}

Suppose we replace the channel for INPA with C1:SUS-LO1_ULCOIL_OUT16, what about INPB. Is this even the right thing to do as I am just guessing here?

After some work on the reference database file, we now have a template for temporary watchdog implementation for LO1 located here "/cvs/cds/caltech/target/c1susaux/C1_SUS-AUX_LO1.db".

Basically, what I have done is swap the EPICS asyn analog input readout for the COIL and OSEM to accessible medm channels, then write out watchdog enable/disable to coil filter SW2 switch. Everything else in the file remains the same. I am worried about some of the conversions but the only way to know more is to see the output on the medm screen.

To test, I restarted c1su2 but this did not make the LO1 database available, so I am guessing that we also need to restart the c1sus, which can be done tomorrow.

Temp software watchdog now operational for LO1 and the remaining optics!

Koji helped me understand how to write to switches and we tried for a while to only turnoff the output switch of the filters instead of the writing a zero that resets everything in the filter.

Eventually, I was able to move this effort foward by realising that I can pass the control trigger along multiple records using the forwarding option 'FLNK'. When I added this field to the trigger block, record(dfanout,"C1:SUS-LO1_PUSH_ALL"), and subsequent calculation blocks, record(calcout,"C1:SUS-LO1_COILSWa") to record(calcout,"C1:SUS-LO1_COILSWd"), everything started working right.

All done (almost)! I still have not sorted the issue of pitch and yaw gains growing together when modified using ramping time. Image of custom ADC and DAC panel is attached.

[Ian, Tega]

Connected the New SUS screens to the controller for the simplant model. Because of hard-coded links in the medm screen links, it was necessary to create the following path in the c1sim computer, where the new medm screen files are located:

We noticed a few problems:

1. Some of the medm files still had C1 hard coded, so we need to replace them with $IFO instead, in order for the custom damping filter screen to be useful.

2. The "Load coefficient" button was initially blank on the new sus screen, but we were able to figure out that the problem came from setting the top-level DCU_ID to 63.

[TODO]

Get the data showing the controller damping the pendulum. This will involve tweaking some gains and such to fine-tune the settings in the controller medm screen. Then we will be able to post some data of the working controller.

[Useful aside]

We should have a single place with all the instructions that are currently spread over multiple elogs so that we can better navigate the simplant computer.

[Ian, Paco, Tega]

Last night we set up the four main matrices that handle the conversion between the degrees of freedom bases and the sensor bases. We also wrote a bash script to automatically set up the system. The script sets the four change of bases matrices and activates the filters that control the plant. this script should fully set up the plant to its most basic form. The script also turns off all of the built-in noise generators. 

After this, we tried damping the optic. The easiest part of the system to damp is the side or y motion of the optic because it is separate from the other degrees of freedom in both of the bases. We were able to damp that easily. in attachment 1 you can see that the last graph in the ndscope screen the side motion of the optic is damped. Today we decided to revisit the problem.

Anyways, looking at the problem with fresh eyes today, I noticed the in pit2pit coupling has the largest swing of all the plant filters and thought this might be the reason why the inputs (UL,UR,LR,LL) to the controller was hitting the rails for pit DoF. I reduce the gain of the pit2pit filter then slowly increased it back to one. I also reduced the gain in the OSEM input filter from 1 to 1/100. The attached image (Attachment2) is the output from this trial. This did not solve the problem. The output when all OSEM input filter gain set to one is shown in Attachment2.

We will try to continue to tweak the coefficients. We are probably going to ask Anchal and Paco to sit down with us and really hone in on the right coefficients. They have more experience and should be able to really get the right values.