Dave, Cao, Evan

We wanted to check briefly how the electronics noise of the PUM coil drivers compares to the excess noise in DARM.

With an SR785, we measured the voltage noise spectra out of the IX and IY coil driver chassises (going to the satellite boxes), and below 80 Hz we found them all to be below to the noise floor of the SR785 (40 nV/rtHz at 10 Hz, 10 nV/rtHz at 100 Hz). On the other hand, in order to explain a 1/f⁴ DARM noise of 1×10⁻¹⁹ m/rtHz at 30 Hz, this would require a white voltage noise at the coil output of 190 nV/rtHz for a single coil, or 50 nV/rtHz for 16 coils with uncorrelated noise.

If we want a good measurement (not just an upper limit) of this coil driver noise, we should use a FET-buffered preamp for reading out the signal.

While working through the SUSAUX medms (my previous entry), it became clear to many of us (Dave included) that the SUSAUX drop downs from the sitemap linked to old and unused screens.  So, we removed them from the sitemap.  I then reorganized the sitemap in a small way to cleanup.  Most notably, IOO is now in it's seemingly more proper place under the left MAIN side of the sitemap.

Screenshot of new map.  It has been committed to SVN.

Today, Kissel and I worked through completing the following (taken from ECR E1600033) for the SUSAUX QUAD and BS models.  This meant recompiling and restarting h1susauxb123, h1susauxex, and h1susauxey with CDS and building new medms screens.

1) Remove SUS NOISE and VOLT MONs from all UPPER stages of SUSes, and non-globally controlled LOWEST stages, and replace with FAST_I_MONs with same data rate.

2) Remove SUS NOISE and VOLT MONs from frames of 10 SUSes under global control and replace with FAST_I MONs (or Fast LV ESD MONs where applicable) with increased data rate of 16k.

3) We will add associated filter banks for every FAST_I_MON.

Data rate calculations show that there will be a zero sum gain to the Science frames by performing the above (see supporting spreadsheet on DCC page).

New FASTIMON screens are shown below.  All model and medm changes have been committed to the SVN.

Work continued with the install/cabling of the WFS Centering RF Triplexer electronics.

- Powered up new Distribution Amp and whitening chassis
- Installed some of the new RF cabling to the demod and Dist Amplifier. None of the existing cabling was disconnected
- Routed the RF Monitor outputs of the I&Q Demodulator to the Demod Concentrator chassis

reported by Masayuki Nakano (I used this account because the firefox remembers it)

The new ISS second loop medm screen, '/opt/rtcds/userapps/release/psl/common/medm/ISS/PSL_CUST_SECONDLOOP.adl' has been made.

The privious screen is remained as '/opt/rtcds/userapps/release/psl/common/medm/ISS/SL.adl"

Filiberto removed Beckhoff Corner Chassis 4 from the CER. He added two EL3104 terminals at the end of the left rail and swapped the L10 EL9190 terminal for an EL9410 terminal. The two EL3014 terminals were already added to the system manager but disabled. I enabled them. I also added the EL9410 terminal and removed the EL9190 terminal. I checked that the changes matched a scan of the boxes and that an activate configuration worked. I saved the system manager file and committed it to svn (rev 2651). I then used Daniel's GUI to restart everything. I had to start PLC3 by hand.

Last week I updated HartmannSensor.lib to add normalized position channels and committed it to svn (rev 2647). These channels are now available in EPICS:

H1:TCS-ITMX_HWS_POSITIONDETECTOR1XNORM
H1:TCS-ITMX_HWS_POSITIONDETECTOR1YNORM
H1:TCS-ITMX_HWS_POSITIONDETECTOR2XNORM
H1:TCS-ITMX_HWS_POSITIONDETECTOR2YNORM

H1:TCS-ITMY_HWS_POSITIONDETECTOR1XNORM
H1:TCS-ITMY_HWS_POSITIONDETECTOR1YNORM
H1:TCS-ITMY_HWS_POSITIONDETECTOR2XNORM
H1:TCS-ITMY_HWS_POSITIONDETECTOR2YNORM

~1535 1555 hrs. local -> To and from Y-mid 

Next over-fill to be Thursday, Feb. 4th before 4:00 pm

The articulating boom lift, (10,000 lbs.) is blocking the walk way at the corner near HAM 3 & 4. You could climb over the tire, however, the preferred route would be around HAM 1. 

DaveB rebooted the ASC model for me earlier today.  I have confirmed that all of the signals go through the matrices as I expect. 

I have also copied antiwhitening filters into the individual segment filter banks of the new AS 90 WFS, and loaded the whole ASC Foton file

Tomorrow morning, Elli, Cao and I will go with Rich and Fil to measure the relative phase between the I and Q channels of each segment.  After that, we should be ready to start using the new AS 90 channels (setting the analog gain and whitening, digital demod phasing, etc.).

WP #5710

I have added two functions in the PSL ISS front end model. Both are related to the second loop and not to the first loop. The model has been compiled, installed and restarted. The changes I made are:

1. Trigger logic for engaging the second loop
2. A servo to achieve "software AC coupling" in the second loop.

I have not yet tested these functions. Since the changes are additive to the existing model, one can still use the guardian to engage the second loop.

The attached is a half-baked and inaccurate medm which shows the new functions. Even though it is inaccurate, it is conceptually good enough to show what I implemented.

The trigger logic is shown in the right hand side of the screen. It watches the amount of the signal (i.e. SECONDLOOP_SIGNAL) which would go to the inner loop and triggers the second loop when it meets the trigger setting.

The software AC coupling function is show in the left of the screen. When one wants to keep using the manual silder to adjust the offset, one can fill the first row of the matrix which plugs the slider value to the offset point. When one wants a slow servo as the guardian has been doing, one can plug three different error signals and correct the offset point depending on the engagement steps.

Currently, Masayuki is editing the screen.

I finally managed to get the HWS TECs working on the superluminescent diodes. The problem was that the trimpots on the LDTC0520 drivers were not set correctly. Per page 11 of the manual, for a SLED with a thermistor and a TEC, we use trimpot LIM_A to set the cooling current limit and LIM_B to set the heating current limit.

• I added 10 full clockwise turns to SLED1/2 trimpots LIM_A/B. This allows significant control current for the TEC to flow.

The actual temperature on the SLED now goes to the set point temperature.

   The temperature and humidity data for the long term storage Dry Boxes, and Desiccant cabinet. No apparent problems or issues noted with these storage boxes. 

For a while I've been trying out sensor correction from the St1 T240s to the St2 CPS's, in X&Y. I thought this was working at ETMY, but not at ETMX, on closer inspection this seems to be not true. Looking into the model with Dave and JimB, we found that the wrong signals are being sent to the X and Z CPS, but Y is okay. It turns out the X CPS is getting the RZ T240, Y is receiving the Y T240, and Z is getting the X T240. Attached image shows the problem area, circled in red. The T240 signals in the T240 bus to St2 are inverted, the bus is labeled X, Y and Z, but if you follow the wires from the T240 cart matrix they go to RZ, Y, X, as I noted. Even worse, the X CPS is receiving not only the T240 RZ, it's receiving the T240 signal before we subtract the Z drive coupling. No wonder X didn't work.

I'm going to file a work permit, fix the bug and let the rest of the SEI group discuss when LLO should get the fix.

Svn up'd LHO's common guardian masterswitch and watchdog folders:

hugh.radkins@opsws1:masterswitch 0$ svn up
U    states.py
Updated to revision 12509.
hugh.radkins@opsws1:masterswitch 127$ pwd
/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/masterswitch
hugh.radkins@opsws1:masterswitch 0$
hugh.radkins@opsws1:masterswitch 0$ cd ../watchdog/
hugh.radkins@opsws1:watchdog 0$ svn st
hugh.radkins@opsws1:watchdog 0$ svn up
U    states.py
Updated to revision 12509.

I restarted HAM6 and tested by disabling an output leg.  The trip appeared to execute the functions as expected-I did not notice any problem.  Restarted HAM5 and tested, it too turned off the FF and reduced the GS13 gains as expected, no problem noticed.  Restarted HAM4 but did not test (by tripping the platform.)

Restarted HAM3 after enabling the GS13 Switching feature as I wanted to test the problem of the guardian being unable to turn the GS13 gain up without tripping the platform.  This is where I noticed the problem.

When guardian turned up the GS13 gain, the HAM3 tripped and it successfully turned off the FF and lowered the GS13 gains but it left the DAMPing loops engaged.  I thought the restart of the guardian may have been responsible for this behaviour.  I cleared the trip but did not turn off the DAMPing path first.  The ISI did not trip until the GS13s were again toggled to high gain but this time, the DAMPing path was turned off as I would expect.  Okay, maybe first time around problem.  Cleared the trip and again the platform tripped when the GS13 gain changed and again the DAMPing path was left on.  I repeatd and again the DAMPing path was left on.  I disabled the GS13 Gain Switching feature and we made it to isolated and I set the GS13 gains to high with the Command Script.

I've repeated the test on HAM5 and there too, DAMPing path remained on.

Meanwhile ITMX tripped due to LVEA activity, DAMPing path not turned off and this guardian has not been restarted with the new update.  Repeated this on ITMY and it too left the DAMPing path enabled.  Okay, it looks like this DAMPing problem is not related to the current code upgrade.

I will continue to restart the guardian with this current upgrade though as the turning off of the GS13s when tripped is a good thing and generally, the platform can deal with untripping the watchdog with stuff coming out of the DAMPing path, as long as the GS13 are in low gain.  And since HAM2 & 3 can't handle guardian gain switching, they must have the gains toggled manually.

Attached are spectra comparing the SUS ETM L3 LV ESD channels from lock segments before (Jan 24, 2016 03:35:00 UTC) and after (Feb 1, 2016 01:50:00 UTC) the ESD Driver update last Tuesday alog 25175 (and the subsequent ESD fixes on Wed 25204).  Before the install, the channels looked like ADC noise, while they look live now.  The ETMx plot is included, but of course the ETMx ESD is not ON during either lock stretch, so all the plot really says is that something happened to the channels.  Whether or not the ETMy channels look like they actually should, according to various ECRs, is to be determined.