Superseeds alogs 26910 and 26924

Bad news: There is lots of MHzish pick-up on the cables to the ITM L2 coils: ~50mVpk
Good news: The ITM L2 coil noise at low freuency is very good: 1.5nV/rtHz at 25Hz, and we might not care about all that pickup.

Details:
The 10Hz harmonics reported in alog 26910 was a measurement problem, generaterd in Rai's preamplifier box (D060205). The cables pick up on the order of 50mVpk at around 1MHz, which was amplified by 100x, causing slew-rate down-conversion.
This was fixed (in the measurment setup) with a 270nF capacitor in prarallel to the 23.8Ohm cable and coil resistance, resulting in a 24.7kHz pole to cut off the cable pick-up.
 
Plot 1 and 2:
ITMX and ITMY coil noise.
Configuration:
- Everything (coil driver, cable, coil) was connected. The breakout box was inserted between coil driver and cable to the satellite amplifier.
- The L2 cois drivers were both is state 3: Acq Off, LP On, which is the run mode. They are never switched for the ITMs.
- The coil driver inputs were left connected to the DAC/AI. I also sent a 100ctpk, 3kHz signal into H1:SUS-ITM[XY]_L2_DRIVEALIGN_L2L_EXC, corresponing to a 2.6ctpk signal on the DAC. I did this to make sure the DAC is as least flipping bits, which raises its noise level.
- A 270nF capacitor was put in parallel to the coil using a pomona box to avoid saturating the D060205-preamp.
- The preamp has a gain of 100. After the preamp a 100Hz low pass was used (1595Ohm and 1uF) to allow the SR785 to run in the lowest noise mode.

Plot 3:
Noise projection assuming incoherent noise and assuming the ETMs behave the same.


Plot 4:
High frequency noise pick-up on the coil cable (coil driver disconnected).
The dominant noise is at ~1MHz, broadband.
Shown are two traces: one in nominal configuratiuon (green), and one with an additional choke on the cable to the coils.

Plot 5:
Scope trace of the high-frequency signal (only the x100 amplifier is used). The signal is made up of ~10msec bursts every ~100msec.

Plot 6:
All 4 coils (without amplifyer) directly connected to the scope. Note that the grounded inputs of the scope slightly change the signal.

Plot 7:
Scope trace with only an antenna connected to the scope. The signal pickup was largest between the racks - I could not trace it to a source yet.

Rich M., Patrick T.

I noticed that the end Y ISI and SUS watchdogs had tripped. I tried untripping them but they immediately tripped again. Rich found that the BRS was reporting bad. He turned off the sensor correction for RY and turned off the BRS correction to the ground seismometer. He left on the sensor correction for X. I untripped the watchdogs again and they remained untripped.

Daniel, Patrick, Matt

We did a little more rotation stage science today.  The objective was to understand the remaining acceleration mystery, and to confirm that the resistor was helping.  The on-screen EPICS values are the ones being used for acceleration and deceleration, and they now have an upper limit of 65000 (or 65s to reach the maximum speed of 100 RPM).  Note that the on-screen velocity is in units of 0.01% of the maximum, so a value of 10000 gives the maximum speed of 100 RPM, and a value of 100 gives 1 RPM.  (These RPM values are presumably for the motor, not the waveplate.)

We found that with the current firmware settings (which Patrick will append), the 50 Ohm resistor was not necessary, so we removed it.  This means that other waveplates in the field need no hardware modification to achieve the 0.01dg accuracy we are seeing with this rotation stage.

The attached screenshot shows a move from 10W to 2W (velocity = 3000, acc = 6000, dec = 6000) and then from 2W to 10W (velocity = 300, acc = 60000, dec = 60000).  Note that the higher values of acceleration and deceleration for lower velocities result in a smoother ride.

J. Kissel

Continuing the work of Corey et al. have done cleaning up SDF files, (see LHO aLOG 26917), I've gone one level deeper to ensure that all snap files used in the target areas are soft links to locations in the userapps repo. 

There *is* a safe.snap for every front-end model / epics db, of which there are 129. Unfortunately, because they're human construction, there are less OBSERVE.snaps (112) and down.snaps (28). OBSERVE.snaps at least exist for every front-end model / epics db that existed during O1. However, weather station dbs, dust monitor dbs, and pi front-end models are new since O1, so OBSERVE.snaps don't exist for them. Further, down.snaps seem to have only been created for ISC models, the globally controlled SUS models, and the ISC-related beckhoff PLCs. We know the safe.snaps are poorly maintained, and sadly we haven't been in a configuration we'd call OBSERVE.snap worth in a long time, so they're also out of date. On top of all this, each subsystem seems to have a different philosophy about safe vs. down.

Daniel, Sheila, Jamie, and myself were discussing this on Friday, we'd come to the conclusion that it is far too difficult to maintain three different SDF files. If the SDF mask is built correctly, then there should be no difference between the "down" and "safe" state. The inventors of the "safe" state are the SEI and SUS teams because they have actuators strong enough to damage hardware. As such, they've designed the front-end models such that all watchdogs come up tripped and user intervention is required to allow for excitations. So, as the model comes up, it's already "safe" regardless of it's settings. Of course, even though the IFO is "down" at that starting point, we still want the platforms to be fully isolated. So, in that sense, for the ISIs "down" is the same as "OBSERVE." And again, if all settings that change via guardian are correctly masked out, then "safe" is the same as "down" is the same as "observe" and you only need one file. 

So, eventually -- we should get back to having only one file per subsystem. But this will take a good bit of effort to make sure that what's controlled via guardian is masked out of every SDF, and vice versa, that what is masked out of SDF *is* controlled by guardian. The temporary band-aid idea, will be at least to make sure that every model's down is the same as it's safe. Because Corey et al. put a good bit of effort into reconciling the down and safe.snap files today, I've copied all of the down.snap's over to the safe.snaps and committed them to the repo. I've not yet gone as far as to change the safe.snap softlinks to point to the down.snaps, but that will be next.

Anyways -- this aLOGs kinda rambling, because this activity has been disjointed, rushed, and sporadic, but I wanted to get these thoughts down and give an update on the progress. In summary, at least every safe, down, and OBSERVE.snap in the target area is a soft link to the userapps repo, and all of those files in the userapps repo are committed. More tomorrow, maybe.

I just noticed that both flow rate and laser temperature channel are clearly returning bogus values after the first Beckhoff restart this morning (~11:10 PT local -- both CO2X and Y). Flowrate reads 0 Gpm and laser temperature is 999 deg C for both CO2X and CO2Y. Chiller temperature is also showing weird behavior (CHILLER_OUT_GAIN_INMON). I went to check on the chillers and they are working fine (flow rate ~3 Gpm). I'm not sure what other channels are returning bogus number that TCS guardian uses to feed the chiller and ISS servo so I request those guardian nodes to be DOWN and turn off the CO2 laser for now until the issue is solved (hopefully tomorrow). I don't think it's a good idea to have them running when the temperature readback and chiller readback are bogus (although the interlock is probably looking at something else, since these values didn't trip the laser). Also we don't have the IFO at the moment.

The parameters for power and angle calculator also reset themselves to either 1 or 0 after SOME Beckhoff restart (see LASERPOWER_POWER_IN channel for example). I was told that TCS stuff is controlled by PCL3. Everytime this happens all the parameters have to be restored by hand. Not cool. So be mindful to check these parameters after every Beckhoff restart and don't just lase the laser (luckily when this happen the laser switch is turned off). It will immediately blast 5W out to the ITMs (whatever happened made the CO2 rotation stages moved too).

POPX: DC works, RF not.

DC responds to flashlight.

We tried to measure the transfer function from RF test input to the RF output on the feedthrough panel at ISCT1, but didn't obtain anything reasonable. We'll swap the head tomorrow.

As a side note, multiple-coax connectors are a pain to work with.

We discovered some build issues which meant we missed today's deadline to upgrade the CDS frontends and DAQ to RCG3.0. We are now ready for a second try tomorrow.

The main issue was tracked to a difference in the version of PERL running on the build machines, with h1build running 5.8.8 and l1build running 5.12.2. A condition statement in the perl module SUM.pm was performing a comparison with the return of a length() call with a null string ( eq "" ) which works with the later version but not with the older version. This line was changed to a numeric comparison ( == 0) which works for all versions.

Several other build issues:

• Changes to common parts required changes to SUS-AUX models to resync the DAQ block with the channel names (TPs were replaced with filtermodules, so DAQ channel names now end in _OUT_DQ).
• Latest version of sus/common/models/STATE_BIO_MASTER.mdl installed to support the reduction of inputs to the TOP function call from 6 to 5 inputs.
• Installed cds/h1/src/ccodeio.h and cds/common/src/ccodeio.h files.
• LSC and PSLISS filter files were not symbolic links from chans to userapps, this was fixed and changes committed to repository

Rolf has included the SUM.pm fix in the next tagged release RCG3.0.2

Betsy has some SUS changes she will install first thing Tuesday morning. After this we will do a clean build and install before shutting all systems down for the upgrade.

We inspected all the relevant optical surfaces that we have access to in the High Power Oscillator.

No damage was visible.  A couple of small dust specks were found and either blown off or wiped off.  

Using the bright green flashlight (thank you JeffB) we identified what looked like water spots on the output coupler and one of the quartz rotators.

They were removed by wiping with isopropanol.

We had a brief telecon with OlliP, MikeF, and MattH at LLO.  The game plan for tomorrow is to propagate a low-power Front End beam through the HPO and look for alignment issues. 

Then, to bring each laser head up at low power and look for optical damage (scattering centers) as the pump power increases.

We plan to continue with this work first thing tomorrow morning.

Status of H1: down for inspection of PSL / HPO

Activities:

- tomorrow the biggest Mantenance activities are 

May  2 12:08:37 h1conlog1-master conlog: ../conlog.cpp: 301: process_cac_messages: MySQL Exception: Error: Data too long for column 'value' at row 1: Error code: 1406: SQLState: 22001: Exiting.

Coincident with Bechoff restarts?

I assumed that the same noise is present in all 16 coils, but is incoherent, i.e. the scaling factor was sqrt(16)=4. Note that the 10Hz and harmonics are due to pick-up, and thus likely coherent at least in the ITMs. Thanks to the alternating magnet polarity, this coupling likely cancels to some degree for length noise, i.e. the attached plot is an over-estimate.

Because we were focused on the QUAD-centric susaux model changes last month (alog 25313), we screwed up the DAQ channel lists for the HAM models (h1susauxh2, h34, h56) after a change to the master FOUROSEM library part.  We turned the NOISEMONs for this library part into filter banks so they needed an _OUT in their channel names.  I fixed these today for the 3 sus ham models and Dave recompiled.  We have more work to do on these models as per existing ECRs.  See attached for an example of how I've left these DAQ channel lists.  Note, we still need to deal with the VOLTMONs and switch the T SIXOSEM library part Noisemons.

(see also alog 26902)

I measured the PUM coild driver noise of the ITMs at the coil driver output.

Bottom line: 

 - All 8 chammels (4 ITMX & 4 ITMY) show the same nosie. 

 - There is significant pickup in the cable running from driver to coil. This corresponsds to the 10msec bursts every 100msec mentioned in alog 26902)

 - This pick-up leads to 10Hz and harmonics.

 - There is some residual pickup of the same signal in the coil driver, but significantly less.

 - above 10kHz there is a huge amount of junk flying around (10uV/rtHz and more !)

The 4 traces in the plots correspond to

Blue: Coil driver output, terminated with 50Ohm.

Red: Coil driver output, with cable and coil attached.

Yellow:  Only cable and coil attached. Coil driver disconneced.

Purple: Measurement noise. (Only terminted breakout box)

Attached are 

plot 1: 0-200Hz (for example ITMY coil 3)

plot 2 & 3: 0-100kHz (for example ITMY coil 1 & 4) Note the 3kHz line - it corresponds to a 100cts 3kH length drive, resuling in about +-2ct at the ADCs.

Matt, Jenne

On Thursday (Apr 28) at about 6:20pm local, while Rick and Keita were in the PSL, Jenne and I made some measurements of the ISS first loop PDs.  Rick told us that there was no light on the ISS PDs at the time of our measurement, so we were hoping to get a dark spectrum to compare with the ones that Sheila and I took on the 24th and to add to the ones that Peter took.  I took a bunch of photos of the results, but later wasn't sure of the state of affairs for each photo, so I went out again today to get a better organized set of measurements.  At present, there is no light on the ISS PDs, so this is a DARK noise measurement.  The aim here is to get high-frequency (10kHz - 10MHz) noise measurements which are complementary to the ones taken by Even and Stefan on Friday using the digital system.

I started by cabling-up a readout system which included a fast o'scope, an SR785 for sub-100kHz spectra, and an RF analyzer for MHz spectra.  To avoid loading the OP27 outputs with 50 Ohms, I made a Pomona box with a 4.7kOhm resistor and 33nF cap in series for the RF path.  When loaded with 50 Ohms (by the RF analyzer) this gives -40dB of attenuation and a 1kHz high-pass.  (The 100 Ohm output impedance of the ISS board or ISS PD doesn't cause problems.)

The first 2 pictures show the output of the PDA monitor from the ISS board.  The same 36.6kHz rep-rate noise bursts that Sheila and I saw are present, though they don't look clipped the way they did when the system was running.  In the RF spectrum, these bursts appear as a comb of lines spread from ~100kHz to ~1.5MHz with a 36.56kHz spacing.  There was nothing interesting above 2MHz.

Photos 3-5 show the result of disconnecting the input.  The noise bursts go away, but since most of the noise is above 100kHz, the SR785 spectrum looks pretty similar (just the peak at 36.6kHz is gone).  The result was similar when I terminated the PDA input on the ISS board with 50 Ohms.  This, and what follows, appears to exonerate the ISS servo board.

Photos 6-8 show the result of placing a 100Hz low-pass in the line coming from the PSL to the PDA input.  The idea here is to attenuate the MHz content on the signal path by > 60dB so that we can see what is on the ground.  The pomona box I used was something that Stefan made for his coil driver measurements: 1.6kOhm and 1uF.  This may not be the optimal way of doing this, but if the RF were all on the signal side it would go away... which it did not.  The RF is much smaller (factor of ~5), but still clearly visible in the time series and the RF spectrum.

Finally, photos 9 and 10 show the output of PDA directly from the PSL.  While qualitatively similar to the monitor output shown in photos 1 and 2, it has more RF junk.  The sub-100kHz spectrum also has a lot more content in this configuration, and while watching it I noticed that there were features moving around with time.  (I made a video, but I can't post it to the log.  Ask me if you want it.)  This smells like RFI to me.