40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 286 of 330  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  13822   Mon May 7 16:23:06 2018 gautamUpdateGeneralDARM actuation estimate

Summary:

Using the Wiener Filter estimate of the DARM disturbance we will have to cancel, I computed how the control signal would look like for a few scenarios. Our DACs are 16-bit, +/-10V (i.e. +/-32,768cts-pk, or ~23,000cts RMS). We need to consider the shape of the de-whitening filter to conclude whether it is feasible to increase the series resistance by x10 or not.

Some details:

Note that in this first computation, I have not considered

  • Actuation range required by other loops (e.g. local damping, Oplev etc).
  • At some point, I need to add the 2P/c radiation pressure disturbance as well.
  • The control signal is calculated assuming we are actuating equally on both ETMs (but with opposite phase).
  • RMS computation is done from 30 Hz downwards, as above 30 Hz, I think the estimate from the previous elog is not true seismic displacement. 
  • De-whitening filters (or digital whitening), which will be required to suppress DAC noise at 100Hz.
  • DARM loop shape, specifically low-pass to avoid sensing noise injection. In this calculation, I just used the pendulum transfer function.

While doing this calculation, I have accounted for the fact that right now, the analog de-whitening filters in the ETM drive chain have a x3 gain which we will remove. Actually this is an assumption, I have not yet measured a transfer function, maybe I'll do one channel at EY to confirm. Also, the actuator gains themselves need to be confirmed.

As I was looking at the coil driver schematic more closely, I realized that there are actually two separate series resistances, one for the fast controls path, and another for the DC bias voltage from the slow ADCs. So I think we have been underestimating the Johnson noise of the coil drivers by sqrt(2). I've also attached screenshots of the IFOalign and MCalign screens. The two  ITMs and ETMX have pitch DC bias values that are compatible with a x10 increase of the series resistance. But even so, we will have ~3pA/rtHz per coil from the two resistances.


gautam 8pm May8: Seems like I had confirmed the x3 gain in the EX de-whitening board when Johannes and I were investigating the AI board offset.

Attachment 1: darmProj.pdf
darmProj.pdf
Attachment 2: 37.png
37.png
Attachment 3: MCalign_20180507.png
MCalign_20180507.png
  13823   Mon May 7 20:01:14 2018 RorpheusUpdateGeneralUse anti-dewhitening + show CARMA/DARMA

What If I Told You - What If I Told You that bogus plots are fake news

example of plots illustrating DAC range / saturation

  13826   Tue May 8 11:41:16 2018 gautamUpdateGeneralIFO maintenance

There was an earthquake, all watchdogs were tripped, ITMX was stuck, and c1psl was dead so MCautolocker was stuck.

Watchdogs were reset (except ETMX which remains shutdown until we finish with the stack weight measurement), ITMX was unstuck using the usual jiggling technique, and the c1psl crate was keyed.

Attachment 1: ITMX_stuck.png
ITMX_stuck.png
  13827   Wed May 9 17:30:04 2018 gautamUpdateGeneralInput beam misaligned

There is no beam going into the IFO at the moment. There was definitely a spot on the AS camera after I restored the suspensions yesterday, as you can see from the ASDC level in Attachment #1. But at around 2pm Pacific yesterday, the ASDC level has gone to 0. I suspect the TTs. There is no beam on the REFL camera either when PRM is aligned, and PRM's DC alignment is good as judged by Oplev.

Normally, I am able to recover the beam by scanning the TTs around with some low frequency sine waves, but not today. We don't have any readback (Oplev/OSEM) of the TT alignment, and the DC bias values havent jumped abnormally around the time this happened, judging by the OUT16 monitor points (see Attachment #2). The IMC was also locked at the time when this abrupt drop in ASDC level happened. Unfortunately, we don't have a camera on the Faraday so I don't know where the misalignment is happening, but the beam is certainly not making it to the BS. All the SOS optics (e.g. BS, ITMX and ITMY) are well aligned as judged by Oplev.

Being debugged now...

Attachment 1: InputBeamGone.png
InputBeamGone.png
Attachment 2: TTpointing.png
TTpointing.png
  13828   Wed May 9 19:51:07 2018 gautamUpdateGeneralInput beam misaligned

As suspected - the problem was with the TTs. I tested the TT signal chain by driving a low frequency sine wave using AWG and looking at the signal on an o'scope. But I saw nothing, neither at the AI board monitor point, nor at the actual coil driver mon point. I decided to look at the IOP testpoints for the DAC channels, to see if the signals were going through okay on the digital side. But the IOP channels were flatlined, as viewed on dataviewer (see Attachment #1). This despite the fact that the DAC output monitor screen in the model itself was showing some sensible numbers, again see Attachment #1.

Looking at the CDS overview screen, there were no red flags. But there was a red indicator sneakily hidden away in the IOP model's CDS status screen, the "DAC" field in the state word is red. As Attachment #2 shows, a change in the state word is correlated with the time ASDC went to 0.

Note that there are also no errors on the c1lsc frontend itself, judging by dmesg. I want to do a model restart, but (i) this will likely require reboots of all vertex FEs and (ii) I want to know if any CDS experts want to sniff for clues to what's going on before a model restart wipes out some secret logfiles. I'm a little confused that the rtcds isn't throwing up any errors and causing models to crash if the values are not being written to the registers of the DAC. It may also be that the DAC card itself is dead sad. To re-iterate, all the EPICS readbacks were suggesting that I am injecting a signal right up to the IOP.

Quoting from the runtime diagnostics note:

NOTE: As V2.7, if this error is detected, the IOP will output zero values to all DAC modules, as a protective measure. Only method to clear this is to restart the IOP and all applications on that computer
Attachment 1: DACweirdness.png
DACweirdness.png
Attachment 2: DACerror.png
DACerror.png
  13829   Thu May 10 08:45:16 2018 SteveUpdateGeneral4.5M eq. Cabazon, CA

20180508 4:49am Cabazon earth quake 4.5M at 79 miles away.  ETMX is in load cell measurment condition.

Quote:

There was an earthquake, all watchdogs were tripped, ITMX was stuck, and c1psl was dead so MCautolocker was stuck.

Watchdogs were reset (except ETMX which remains shutdown until we finish with the stack weight measurement), ITMX was unstuck using the usual jiggling technique, and the c1psl crate was keyed.

 

Attachment 1: Cabazon4.5m79m.png
Cabazon4.5m79m.png
Attachment 2: 4.5Meq.png
4.5Meq.png
  13830   Thu May 10 11:38:19 2018 gautamUpdateGeneralITMY UL

Looking at Steve's plot, I was reminded of the ITMY UL OSEM issue. The numbers don't make sense to me though - 300um of DC shift in UL with negligible shifts in the other coils should have made a much bigger DC shift in the Oplev spot position.

Attachment 1: ITMY_UL.pdf
ITMY_UL.pdf
  13831   Thu May 10 14:13:22 2018 gautamUpdateGeneralMore refinement of DARM control signal projection

Summary:

  1. It seems that after a x10 increase in the coil driver resistance, we will have enough actuation range to control (anti de-whitened) DARM without saturating the DAC.
  2. The Barry puck doesn't seem to help us much in reducing the required RMS for DARM control. If this calculation is to be believed, it actually makes the RMS actuation a little bit higher.

See Attachment #1 for the projected control signal ASDs. The main assumption in the above is that all other control loops can be low-passed sufficiently such that even with anti-dewhitening, we won't run into saturation issues.

DARM control loop:

  • I'm now calculating the DARM control signal in counts after factoring into account a digital DARM control loop.
  • The loop shape is what we used when the DRFPMI was locked in Oct 2015.
  • I scaled the overall OLTF gain to have a UGF around 200Hz.
  • The breakdown of how the DARM loop is constructed is shown in Attachment #2.

De-whitening and Anti-De-whitening:

  • The existing DW shape in the ITM and ETM signal chains has ~80dB attenuation around 100 Hz.
  • Assuming ~5uV/rtHz noise from the DAC, 60dB of low-passing gets us to 5nV/rtHz. With 4.3kohm series resistance, this amounts to ~1pA/rtHz current noise (compared to ~3pA/rtHz from the Johnson noise of the series resistance). Actually, I measured the DAC noise to be more like ~700nV/rtHz at 100 Hz, so the current noise contribution is only 0.16pA/rtHz.
  • This amounts to getting rid of the passive filter at the end of the chain in the de-whitening board.
  • Attachment #3 shows the existing and proposed filter shapes.

It remains to add the control signals for Oplev, local damping, and ASC to make sure we have sufficient headroom, but given that current projections are predicting using up only ~1000cts of the ~23000cts (RMS) available from the DAC, I think it is likely we won't run into saturations. Need to also figure out what the implication of the reduced actuation range will be on handling the locking transient.

Attachment 1: darmProj.pdf
darmProj.pdf
Attachment 2: darmOLTF.pdf
darmOLTF.pdf
Attachment 3: DWcomparison.pdf
DWcomparison.pdf
  13833   Fri May 11 13:58:42 2018 ranaUpdateGeneralMore refinement of DARM control signal projection

I think "OLG" trace is not labeled right; it would be good to see the actual OLG in addition to whatever that trace actually is.

Based on the first plot, however, my conclusion is that:

  1. we don't need the passive isolator to reduce the control signal; the control signal is dominated by f < 10 Hz.
  2. we should still look into isolators for the reduction of the f > 50 Hz stuff, just to make the overall DARM sensitivity better. But this does not have to be pneumatic since we no longer need 10 Hz isolation. It can instead be a solid piece of rubber to give us a ~20-30 Hz resonance. That would still give us a factor of 5-10 improvement above 100 Hz.
  3. In this case, we only need a mass estimate of the end chamber contents with an accuracy of ~25%. If we think we have that already, we don't need to keep doing the jacks-strain gauge adventure.
  13834   Fri May 11 18:17:07 2018 gautamUpdateDetCharAUX laser PLL setup

[koji, gautam]

As discussed at the meeting earlier this week, we will use some old *MOPA* channels for interfacing with the PLL system Jon is setting up. He is going to put a sketch+photos up here shortly, but in the meantime, Koji helped me identify a channel that can be used to tune the temperature of the Lightwave NPRO crystal via front panel BNC input. It is C1:PSL-126MOPA_126CURADJ, and is configured to output between +/-10V, which is exactly what the controller can accept. The conversion factor from EPICS value to volts is currently set to 1 (i.e. EPICS value of +1 corresponds to +1V output from the DAC). With the help of the wiring diagram, we identified pins 3 and 4 on cross-connect #J7 as the differential outputs corresponding to this channel. Not sure if we need to also setup a TTL channel for servo ENABLE/DISABLE, but if so, the wiring diagram should help us identify this as well. 

The cable from the DAC to the cross-connect was wrongly labelled. I fixed this now.

  13835   Fri May 11 19:02:52 2018 gautamUpdateGeneralMore refinement of DARM control signal projection

I was a bit hasty in posting the earlier plots. In the earlier plot, the "OLG" trace was OLG * anti dewhitening as Rana pointed out.

Here are the updated ones, and a cartoon (Attachment #5) of the loop topology I assumed. I've excluded things like violin filters, AA/AI etc. The overall gain scaling I mentioned in the previous elog amounts to changing the optical sensing response in this cartoon. I now also show the DARM suppression (Attachment #4) for this OLG and the DARM linewidths for RSE. I don't think the conclusions change.

Note that for Signal Recycling, which is what Kevin tells us we need to do, there is a DARM pole at ~150 Hz. I assume we will cancel this in the digital controller and so can achieve a similar OLG shape. This would modify the control signal spectrum a little around 150Hz. But for a UGF on the loop of ~150 Hz, we should still be able to roll-off the control signal at high frequencies and so the RMS shouldn't be dramatically affected.

Steve is looking into acquiring 4.5kohm Vishay Wirewound resistors with 1% tolerance. Plan is to install two in parallel (so that we get 2kohm effective resistance) and then snip off one once we are convinced we won't have any actuation range issues. Do these look okay? They're ~$1.50ea on mouser assuming we get 100. Do we need the non-inductive winding?

Quote:

I think "OLG" trace is not labeled right; it would be good to see the actual OLG in addition to whatever that trace actually is.


Attachment 1: darmProj.pdf
darmProj.pdf
Attachment 2: darmOLTF.pdf
darmOLTF.pdf
Attachment 3: DWcomparison.pdf
DWcomparison.pdf
Attachment 4: DARMsuppression.pdf
DARMsuppression.pdf
Attachment 5: ControlLoop.pdf
ControlLoop.pdf
  13836   Sat May 12 10:02:03 2018 ranaUpdateGeneralMore refinement of DARM control signal projection

Good question! I've never calculated what the resonance frequency would be if had an inductive resistor with our cable capacitance (~50 pF/m I guess).

  13837   Sun May 13 15:15:18 2018 gautamUpdateGeneralCDS crash

I found the c1lsc machine to be completely unresponsive today. Looking at the trend of the state word, it happened sometime yesterday (Saturday). The usual reboot procedure did not work - I am not able to bring back any of the models on any of the machines, during the restart procedure, they all fail. The logfile reads (for the c1ioo front end, but they all behave the same):

[  309.783460] c1x03: Initializing space for daqLib buffers
[  309.887357] CPU 2 is now offline
[  309.887422] c1x03: Sync source = 4
[  309.887425] c1x03: Waiting for EPICS BURT Restore = 2
[  309.946320] c1x03: Waiting for EPICS BURT 0
[  309.946320] c1x03: BURT Restore Complete
[  309.946320] c1x03: Corrupted Epics data:  module=0 filter=1 filterType=0 filtSections=134610112
[  309.946320] c1x03: Filter module init failed, exiting
[  363.229086] c1x03: Setting stop_working_threads to 1
[  364.232148] DXH Adapter 0 : BROADCAST - dx_user_mcast_unbind - mcgroupid=0x3
[  364.233689] Will bring back CPU 2
[  365.236674] Booting Node 1 Processor 2 APIC 0x2
[  365.236771] smpboot cpu 2: start_ip = 9a000
[  309.946320] Calibrating delay loop (skipped) already calibrated this CPU
[  365.251060] NMI watchdog enabled, takes one hw-pmu counter.
[  365.252135] Brought the CPU back up
[  365.252138] c1x03: Just before returning from cleanup_module for c1x03

Not sure what is going on here, or what "Corrutped EPICS data" is supposed to mean. Thinking that something was messed up the last time the model was compiled, I tried recompiling the IOP model. But I'm not able to even compile the model, it fails giving the error message

make[1]: Leaving directory '/opt/rtcds/caltech/c1/rtbuild/3.4'
make[1]: /cvs/cds/rtapps/epics-3.14.12.2_long/modules/seq/bin/linux-x86_64/snc: Command not found
make[1]: *** [build/c1x03epics/c1x03.c] Error 127
Makefile:28: recipe for target 'c1x03' failed
make: *** [c1x03] Error 1

I suspect this is some kind of path problem - the EPICS_BASE bash variable is set to /cvs/cds/rtapps/epics-3.14.12.2_long/base on the FEs, while /cvs isn't even mounted on the FEs (nor do I think it should be). I think the correct path should be /opt/rtapps/epics-3.14.12.2_long/base. Why should this have changed?

I've shutdown all watchdogs until this is resolved.

Attachment 1: vertexFEs_crashed.png
vertexFEs_crashed.png
  13838   Sun May 13 17:31:51 2018 gautamUpdateGeneralCDS crash

As suspected, this was indeed a path problem. Johannes will elog about it later, but in short, it is related to some path variables being changed in order to try and streamline the EPICS processes on the new c1auxex machine (Acromag Era). It is confusing that futzing around with the slow computing system messes with the realtime system as well - aren't these supposed to be decoupled? Once the paths were restored by Johannes, everything compiled and restarted fine. We even have a beam on the AS camera, which was what triggered this whole thingyes.

Anyways, Attachment #1 shows the current status. I am puzzled by the red TIMING indicators on the c1x04 and c1x02 processes, it is absent from any other processes. How can this be debugged further?

Quote:
 

I suspect this is some kind of path problem - the EPICS_BASE bash variable is set to /cvs/cds/rtapps/epics-3.14.12.2_long/base on the FEs, while /cvs isn't even mounted on the FEs (nor do I think it should be). I think the correct path should be /opt/rtapps/epics-3.14.12.2_long/base. Why should this have changed?

Attachment 1: CDS_overview_20180513.png
CDS_overview_20180513.png
Attachment 2: AS_1210293643.jpeg
AS_1210293643.jpeg
  13839   Sun May 13 20:48:38 2018 johannesUpdateGeneralCDS crash

I think the root of the problem is that the /opt/rtapps/ and /cvs/cds/rtapps/ mounting locations point to the same directory on the nfs server. Gautam and I were cleaning up the /cvs/cds/caltech/target/ directory, placing the previous contents of /cvs/cds/caltech/target/c1auxex/, including database files and startup instructions in /cvs/cds/caltech/target/c1auxex_oldVME/, and then moved /cvs/cds/caltech/target/c1auxex2/, which has the channel database and initialization files for the Acromac DAQ, to /cvs/cds/caltech/target/c1auxex/.

This also required updating the systemd entries on c1auxex to point to the changed directory. While confirming that everything worked as before we noticed that upon startup the EPICS IOC complains about not being able to find the caRepeater binary. This was not new and has not limited DAQ functionality in the past, but we wanted to fix this, as it seemed to be some simple PATH issue. While the paths are all correctly defined in the user login shell, systemd runs on a lower level and doesn't know about them. One thing we tried was to let systemd execute /cvs/cds/rtapps/epics-3.14.12.2_long/etc/epics-user-env.sh initializing EPICS. It was strange that the content of that file was pointing to /opt/rtapps/epics-3.14.12.2_long/base, which is not mounted on the slow machines, so we changed the /opt/ it to /cvs/cds/, not realizing that the frontends read from the same directory (as Gautam said, /cvs/cds does not exist as a mount point on the frontend). It ended up not working this way, and apparently I forgot to change it back during clean up. But worse, never elogged it!

In the end, we managed to to give systemd the correct path definitions by explicitly calling them out in /cvs/cds/caltech/target/c1auxex/ETMXenv, to which a reference was added in the systemd service file. The caRepeater warning no longer appears.

  13841   Mon May 14 18:58:32 2018 KevinUpdatePonderSqueezeSqueezing with no SRM
Quote:

Note that for Signal Recycling, which is what Kevin tells us we need to do, there is a DARM pole at ~150 Hz.

To be quantitative, since we are looking at smaller squeezing levels and considering the possibility of using 5 W input power, it is possible to see a small amount of squeezing below vacuum with no SRM.

Attachment 1 shows the amount of squeezing below vacuum obtainable as a function of homodyne angle with no SRM and 5 W incident on the back of PRM. The optimum homodyne angle at 210 Hz is 89.2 deg which gives -0.38 dBvac of squeezing. Figure 2 is the displacement noise at this optimal homodyne angle and attachment 3 is the same noise budget shown as the ratio of the various noise sources to the unsqueezed vacuum.

The other parameters used for these calculations are:

  • 4.5 kΩ series resistance for the ETM coils; 15 kΩ for the ITM coils
  • 100 ppm transmissivity on the folding mirrors giving a PRC gain of 40
  • PD quantum efficiency of 0.88

So maybe it's worth considering going for less squeezing with no SRM if that makes it technically more feasible.

Attachment 1: homodyne_heatmap.pdf
homodyne_heatmap.pdf
Attachment 2: displacement_noise.pdf
displacement_noise.pdf
Attachment 3: noise_budget.pdf
noise_budget.pdf
  13842   Tue May 15 10:42:14 2018 KojiUpdatePSLModulation depth measurement for the 3IFO aLIGO EOM and aftermath

The marconi RF output was turned on and thus the RF generator condition was restored to the nominal state on Friday 11th.

  13843   Tue May 15 13:34:30 2018 SteveUpdatesafetysurf safety training

Pooja and Keirthana received 40m specific basic safety training.

  13846   Tue May 15 21:56:57 2018 gautamUpdateGeneralStack measurement setup decommissioned

[steve,koji,gautam]

Since we think we already know the stack mass to ~25% (i.e. 5000 +/- 1000 lbs), we decided to restore the ETMX stack. Procedure followed was:

  • Take photos of all dial indicators and spirit level. We were at ~-22 mils on all 3 indicators, with 0 being the level before we touched the stack two Fridays ago, i.e. May4.
  • Raised all four jacks installed underneat blue crossbeams in 5mil increments until we were at +25mils on all of them. At this point, there was negligible load on the load cells on top of the STACIS legs, and we could easily slide the load cells out.
  • Rotated all jack screws clockwise (i.e. moving jack screws downwards) by 270 degrees. The southeast jackscrew was rotated by an additional 360 degrees. This was to undo all the jack-screw raising we did on Friday, May 4.
  • Re-installed jacks which were present originally on the STACIS legs, taking care to center the jack as best as we could by eye on the STACIS leg, per Dennis Coyne's suggestion not to impose shear strain on STACIS legs. There were supposedly never carrying any load, and are according to Steve, are there more for safety purposes.
  • Lowered all four jacks in 5 mil steps until dial indicators read ~0. The Northwest jack resting on the STACIS leg was somehow ~0.5cm (!!) below the blue crossbeam even though the corresponding dial gauge read 0, so we raised the jack until it was barely grazing the bottom of the blue crossbeam (confirmed by looking at the point where the dial indicator started going up again). Not sure why this should have been, best hypothesis we have is that someone (one of us) changed the level of this jack while it was removed from the setup.
  • Checked that jack screws could not be turned by hand. At this point, all the load has to be resting on the jack screws, as the jacks we had installed to raise the blue crossbeams could be slid out from underneath the blue beams and hence were carrying no load.
  • Took photographs of all dial indicators, spirit level. We were satisfied that we had recovered the "nominal" stack alignment as best as we could judge with the available indicators.
  • ETMX Oplev spot had returned to the PD. ETMX watchdog was re-engaged, optic was re-aligned using SLOW bias sliders to center Oplev spot.
  • EX NPRO was turned back on, and the green beam was readily locked to a cavity TEM00 mode yes.

I will upload the photos to the PICASA page and post the link here later.

Quote:
 

In this case, we only need a mass estimate of the end chamber contents with an accuracy of ~25%. If we think we have that already, we don't need to keep doing the jacks-strain gauge adventure.

 

  13847   Tue May 15 22:11:38 2018 gautamUpdateGeneralIFO maintenance

Since there have been various software/hardware activity going on (stack weighing, AUX laser PLL, computing timing errors etc etc), I decided to do a check on the state of the IFO.

  • c1susaux, c1aux and c1iscaux crates were keyed as they were un-telnet-able.
  • Single arm locking worked fine, TT alignment was tweaked (as these had drifted due to the ADC failure in c1lsc) to maximize Y arm transmission using the dither servos.
  • Arms weren't staying locked for extended periods of time. I particularly suspected ITMX, as I saw what I judged to be excess motion on the Oplev.
  • @Steve - ITMX and BS HeNes look like they are in need of replacement judging by the RIN (although the trend data doesn't show any precipitous drop in power). If we are replacing the BS/PRM Oplev HeNe, might be a good time to plan the inejction path a bit better on that table.
  • RIN in Attachment #1 has been normalized by the mean value of the OL sum channel. There is now a script to make this kind of plot from NDS in the scripts directory (as I found it confusing to apply different calibrations to individual traces in DTT).
Attachment 1: OL_RIN_2018_05_15.pdf
OL_RIN_2018_05_15.pdf
Attachment 2: OLsums.png
OLsums.png
  13849   Wed May 16 21:02:22 2018 KevinUpdatePEMADC common mode rejection with new seismometer connections

As described in this elog, the ADC for the seismometers now has the signals wired directly to the ADC instead of going through an AA board or other circuit to remove any common mode noise. This elog describes one test of the common mode rejection of this setup. Guantanamo suggested comparing directly with a recent spectrum taken a few months before the new setup described in this elog.

Today I took a spectrum (attachment 1) of C1:PEM-MIC_2 (Ch17) and C1:PEM-MIC_3 (Ch18) with input to the ADC terminated with 50 Ohms. These are two of the channels plotted in the previous spectrum, though I don't know how that plot was normalized. It's clear that there are now strong 60 Hz harmonic peaks that were not there before, so this new setup does have worse common mode rejection.

Attachment 1: ADC_noise.pdf
ADC_noise.pdf
  13850   Wed May 16 21:47:17 2018 KevinUpdatePEMSeismometer Noise Spectra

Earlier today Kira and I reconnected the EX seismometer. I just took some spectra of all three seismometers, shown in the attachments, to compare with past data and to do a rough check of the calibration.

This elog has a spectra from 2010 (GUR1 is now EY) and this elog has one for BS at lower frequencies from 2017. Note that the EX seismometers now have strong peaks that are not at 60 Hz harmonics. Other than these peaks, these old spectra roughly match up with the ones taken today, so the callibration is still roughly the same. I couldn't find any old data for EX (GUR2) though so I don't know for sure that these peaks weren't there before.


gautam 20180517 0930: In 2017, Gur2 (now EX) looked like this. Still peaky, but the peaks seem shifted in frequency. Steve also informed me that the Gur1 and Gur2 cables were swapped n times, so perhaps we shouldn't read too much into that.

Attachment 1: BS_vel.pdf
BS_vel.pdf
Attachment 2: EX_vel.pdf
EX_vel.pdf
Attachment 3: EY_vel.pdf
EY_vel.pdf
  13851   Thu May 17 09:14:38 2018 SteveUpdateGeneralStack measurement setup decommissioned

The final set-up of stack measurment with 3 load cells and 4 leveling wedge mounts as Atm 1

Sensor voltages BEFORE and AFTER this attempt.

Attachment 1: Load_Cell_Measurement_Set_Up.jpg
Load_Cell_Measurement_Set_Up.jpg
Attachment 2: ETMX_stack_up_down.png
ETMX_stack_up_down.png
  13852   Thu May 17 11:56:37 2018 gautamUpdateGeneralEPICS process died on c1ioo

The EPICS process on the c1ioo front end had died mysteriously. As a result, MC autolocker wasn't working, since the autolocker control variables are EPICS channels defined in the c1ioo model. I restarted the model, and now MCautolocker works.

  13859   Thu May 17 15:38:19 2018 KiraUpdatePEMtest setup with seismometer

I've moved my setup to the actual seismometer. I attached the temperature sensor to the seismometer (attachment 1) with duct tape, though this is temporary. I will be monitoring the temperature fluctuations of the seismometer for a whole day then take the can off and repeat the test. The can isn't clamped down so the insulation isn't perfect, so I'd expect to see some noticeable fluctuations even with the can on. I've also labeled the long cable for the temperatuse sensor readout (attachments 2 and 3). There will also be an out of loop sensor added in later, but for this test since I am not running the loop it doesn't matter which sensor I monitor. Attachment 4 is a picture of the current setup.

Attachment 1: IMG_20180517_144420.jpg
IMG_20180517_144420.jpg
Attachment 2: IMG_20180517_145754.jpg
IMG_20180517_145754.jpg
Attachment 3: IMG_20180517_151956.jpg
IMG_20180517_151956.jpg
Attachment 4: IMG_20180517_145121.jpg
IMG_20180517_145121.jpg
  13860   Thu May 17 18:05:01 2018 gautamUpdateSUSSR785 near 1X5

I'm working near 1X5 and there is an SR785 adjacent to the electronics rack with some cabling running along the floor. I plan to continue in the evening so please leave the setup as is.

During the course of this work, I noticed the +15V Sorensen in 1X6 has 6.8 A of current draw, while Steve's February2018 label says the current draw is 8.6A. Is this just a typo?

Steve: It was most likely my mistake. Tag is corrected to 6.8A


I'm still in the process of electronics characterization, so the SR785 is still hooked up. MC3 coil driver signal is broken out to measure the output voltage going to the coil (via Gainx100 SR560 Preamp), but MC is locked.

Attachment 1: B55CE985-B703-4282-B716-3144957C7372.jpeg
B55CE985-B703-4282-B716-3144957C7372.jpeg
  13861   Fri May 18 07:41:01 2018 steveUpdateSUSclipping ITMX oplev

The ITMX oplev still clipping

Quote:

The ITMX oplev beam is clipping. It will be corected with locked arm

 

 

  13862   Fri May 18 09:13:41 2018 PoojaUpdateSUSColored GigE image

To obtain a colored version with good contrast of the grayscale image of scattering of light by dust particles on the surface of test mass, got using GigE camera. The original and colored images are attached here.

 

Attachment 1: Image__2017-11-14__08-25-13_100k100g1V_colored.png
Image__2017-11-14__08-25-13_100k100g1V_colored.png
Attachment 2: Image__2017-11-14__08-25-13_100k100g1V.tiff
  13864   Fri May 18 14:33:34 2018 KiraUpdatePEMtest setup with seismometer

Here is the result of my test. I think I'll leave the can on over the weekend because there's a long period of time where the seismometer heated up by 0.8 degrees so I can't fully see the fluctuations over a full 24 hour period.

Attachment 1: seis_temp_can_on.png
seis_temp_can_on.png
  13866   Fri May 18 19:10:48 2018 keerthanaUpdateGeneralCode for adjusting the oscillator frequency remotly

Target: Phase locking can be acheived by giving a scan to the oscilator frequency. This frequency is now controlled using the knobe on the AM/FM signal generator 2023B. But we need to control it remotely by giving the inputs of start frequency, end frequency and the steps.

The frequency oscilator and the computer is connected with the help of GPIB Ethernet converter. The IP address of the converter I used is '192.168.113.109' and its GPIB address is 10.

I could change the oscilator frequency by changing the input frequency with the help of the code I made (Inorder to check this code, I have changed the oscilator frequency multiple times. I hope it didn't create trouble to anyone). Now I am trying to make this code better by adding certain features like numpy, argument parse etc, which I will be able complete by next week. I am also considering to develop the code to have a sliding system to control the oscillatory frequency.

For record: The maximum limit of frequency which i changed upto is 100MHz.

 

Attachment 1: frequency_set.jpg
frequency_set.jpg
  13868   Fri May 18 20:03:14 2018 PoojaUpdateCamerasTelescopic lens solution for GigE

Aim: To find telescopic lens solution to image test mass onto the sensor of GigE camera.

I wrote a python code to find an appropriate combination of lenses to focus the optic onto the camera keeping in mind practical constraints like distance of GigE camera from the optic ~ 1m and distance between the lenses need to be in accordance with the Thorlab lens tubes available. We have to image both the enire optic of size 3" and beam spot of 1" using this combination of lens. The image size that efficiently utilizes the entire sensor array is 1/4". Therefore the magnification required for imaging the entire optic is 1/12 and that for the beam spot is 1/4.

I checked the website of Thorlabs to get the available focal lengths of 2" lenses (instead of 1" lenses to collect sufficient power). I have tried several combination of lenses and the ones I found close enough to what is required have been listed below along with thier colorbar plots.

a) 150mm-150mm (Attachment 2 & 3)

With this combination, object distance varies like 50cm for 1" beam spot to 105cm for 3" spot. Therefore, it posses a difficulty that there is a difference of ~48cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

b) 125mm-150mm (Attachment 4 & 5)

With this combination, object distance varies like 45cm for 1" beam spot to 95cm for 3" spot. There is a difference of ~43cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

c) 125mm-125mm (Attachment 6 & 7)

The object distance varies like 45cm for 1" beam spot to 90cm for 3" spot. There is a difference of ~39cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

Sensitivity check was also done for these combination of lenses. An error of 1cm in object distance and 5mm in the distance between the lenses gives an error in magnification <2%.

The schematic of the telescopic lens system has been given in Attachment 8.

 

Attachment 1: frequency_set.jpg
Attachment 2: plot_2018-05-18_tel-lens_150_150_1.pdf
plot_2018-05-18_tel-lens_150_150_1.pdf
Attachment 3: plot_2018-05-18_tel-lens_150_150_3.pdf
plot_2018-05-18_tel-lens_150_150_3.pdf
Attachment 4: plot_2018-05-18_tel-lens_125_150_1.pdf
plot_2018-05-18_tel-lens_125_150_1.pdf
Attachment 5: plot_2018-05-18_tel-lens_125_150_3.pdf
plot_2018-05-18_tel-lens_125_150_3.pdf
Attachment 6: plot_2018-05-18_tel-lens_125_125_1.pdf
plot_2018-05-18_tel-lens_125_125_1.pdf
Attachment 7: plot_2018-05-18_tel-lens_125_125_3.pdf
plot_2018-05-18_tel-lens_125_125_3.pdf
Attachment 8: tel_design.pdf
tel_design.pdf
  13869   Sun May 20 17:43:01 2018 ranaUpdateElectronicsHow to choose resistors

Article from EE Times, describing why metal foil (NOT metal film) resistors are really better than wirewound when it comes to everything except high power dissipation.

Need to do some diggin to see if we can find ~1k metal foil resistors which can handle ~1W of heat.

Steve: here it is

  13870   Sun May 20 23:43:50 2018 gautamUpdateIOOCoil driver noise re-measurement

Summary:

In the IMC actuation chain, it looks like the MC1/MC3 de-whitening boards, and also all three MC optics' coil driver boards, are showing higher noise than expected from LISO modeling. One possible candidate is thick film resistors on the coil driver boards. The plan is to debug these further by pulling the board out of the Eurocrate and investigating on the electronics bench.

Why bother? Mainly because I want to see how good the IR ALS noise is, and currently, the PSL frequency noise is causing the measurement to be worse than references taken from previous known good times.

Details:

Sometime ago, rana suggested to me that I should do this measurement more systematically.

  • Attachments #1, #2 and #3 show noise measurements in various conditions for MC1, MC2 and MC3 respectively.
  • In the above three attachments, I stitched together multiple spans from the SR785, and so the bin-width is different. The data is downloaded from the analyzer normalized by the bin-width (PSD units).
  • The roll-off at ~800Hz in the orange trace for MC1 and MC3 is consistent with an 800 Hz LPF that was used for anti-image filtering from the old 2 kHz era.
  • While it may look like the analog de-whitening isn't being switched on in some of these plots, I confirmed by transfer function measurement that it is indeed switching.
  • Data used to make these plots are in Attachment #4. Unfortunately, the code requires some of my personal plotting librariesno and so I'm not uploading it.
  • Sketch of measurement setup is shown in Attachment #5. It is not indicated in the schematic, but the SR560 was operated in battery mode for this measurement.
  • For MC1, I did the additional measurement of terminating the LEMO input to the coil driver and measuring (what should have been) just the coil driver electronics noise. But this measurement doesn't look very clean, and hence, the decision to pull the board out to continue debugging.
  • While at 1X6, Rana tightened the LEMO connectors going to MC1. We should opportunistically do MC2 and MC3 as well.
  • Some changes to be made:
    • Thick film ---> thin film.
    • Reroute HPF-ed back-plane Vmon output to the front panel LEMO.

I've now restored all the wiring at 1X6 to their state before this work.

Attachment 1: MC1_coilDriver.pdf
MC1_coilDriver.pdf
Attachment 2: MC2_coilDriver.pdf
MC2_coilDriver.pdf
Attachment 3: MC3_coilDriver.pdf
MC3_coilDriver.pdf
Attachment 4: MC_coilDriverNoises.tgz
Attachment 5: ActuationChainNoiseMeas.pdf
ActuationChainNoiseMeas.pdf
  13871   Mon May 21 10:15:35 2018 gautamUpdatePEMtest setup with seismometer

I guess it's fine for now while we are still finalizing the setup at EX, but we should eventually line up the seismometer axes with the IFO axes. Is there a photo of the orientation of the seismometer pre heater can tests? If not, probably good to make some sort of markings on the granite slab / seismometer to allow easy lining up of these axes...

  13872   Mon May 21 14:17:28 2018 KiraUpdatePEMtest setup with seismometer

I have attached the graph for the seismometer temperature fluctuations over 3 days. As we can see, there is a noticeable fluctuation in daily temperature as well as a difference between days in the maximum and minimum temperatures. I will repeat this test but take the can off to see if there's any difference between having the can on or off.

Attachment 1: seis-temp.png
seis-temp.png
  13874   Mon May 21 17:36:00 2018 poojaUpdateCamerasGigE camera image of ETMX

Today Steve and I tried to to capture the image of scattering of light by dust particles on the surface of ETMX using GigE camera. The image ( at gain =100, exposure time = 125000) obtained has been attached. Unlike the previous images, a creepy shape of bright spots was seen. Gautam helped us lock infrared light and see the image. A similar less intense shape was seen. This may be because of the dust on the lens.

Attachment 1: Image__2018-05-21__17-34-15_125k100g.tiff
  13875   Mon May 21 18:02:55 2018 keerthanaUpdateGeneralTesting of the new mini-circuits frequency counter

Today, I tested the new mini-circuit frequency counter by connecting it with the beat signal output. The frequency counter works fine. Now I am trying to get a display of the frequency in the computer screen using python programming. I have made the code for remotely changing oscilator frequency and it is saved in the folder 'ksnair'. A picture of the new mini circuits frequency counter is attached below. Part no: UFC-6000, S/N: 11501040012, Run: M075270.

Attachment 1: frequency_counter.jpg
frequency_counter.jpg
  13877   Tue May 22 14:49:03 2018 KiraUpdatePEMtest setup with seismometer

It appears that one of the wires was disconnected overnight or this morning so I wasn't able to gather data over a full 24 hour period. Perhaps someone accidentally kicked it. I placed some cones in that area so hopefully the wires won't be in the way as much and I can get the data tomorrow. From the data I do have it seems that the seismometer is at a colder temperature when the can is not on, though it is difficult to see by how many degrees the temperature fluctuates. I've included the data from 5 days back to see the comparison.

Attachment 1: seis-temp-2.png
seis-temp-2.png
  13878   Tue May 22 17:26:25 2018 gautamUpdateIOOMC1 Coil Driver pulled out

I have pulled out MC1 coil driver board from its Eurocrate, so IMC is unavailable until further notice. Plans:

  1. Thick film --> Thin Film
  2. AD797 --> Op27
  3. Remove Pots in analog actuation path.
  4. Measure noise
  5. Route HPF signal (UL DAQ Mon) to front panel. I think we should use the SMA connectors. That way, we have DC and AC voltage monitors available for debugging.

If there are no objections, I will execute Step #5 in the next couple of hours. I'm going to start with Steps 1-4.

  13879   Tue May 22 17:29:27 2018 keerthanaUpdateelogMEDM Diagram for the auxilary laser system control and display.

(keerthana, gautam, jon)

In the morning, Jon gave me an overview of the Auxiliary laser system which we are planning to setup. Based on the diagram he uploaded in the elog, I have made the MEDM diagram for controlling and displaying the parameters. Here the parameters which we will be controlling are temperature (in terms of voltage), oscilator frequency ( with the help of IFR 2023B), the frequency offset and the PID controls. The display includes the beat frequency, error signal voltage, control voltage and a switch to give feed back to the AUX laser. As the frequency counter is not connected at the moment, I haven't included its channel number in it. The screenshot of the diagram is attached with this. I am also considering to give a PID feedback to the slow control from the AUX feedback signal. The screen can be accessed from the PSL dropdown menu in sitemap.

Attachment 1: MEDM_aux.png
MEDM_aux.png
  13880   Tue May 22 23:28:01 2018 gautamUpdateIOOMC1 Coil Driver pulled out

This work is now complete. MC1 coil driver board has been reinstalled, local damping of MC1 restored, and IMC has been locked. Detailed report + photos to follow, but measurement of the noise (for one channel) on the electronics workbench shows a broadband noise level of 5nV/rtHz (yes) around 100Hz, which is lower than what was measured here and consistent with what we expect from LISO modeling (with fast input terminated with 50ohm, slow input grounded).

Quote:

I have pulled out MC1 coil driver board from its Eurocrate, so IMC is unavailable until further notice.

 

  13882   Wed May 23 14:50:33 2018 KiraUpdatePEMtest setup with seismometer

This time the test went without issue. The first attachment is the data for the past 24 hours and the second attachment is the full data over 6 days. The average temperature fluctuations (from highest point to lowest point) for the can on was 0.43 C and for the can off it came out to 0.55 C. In addition the seismometer with the can off is about 1 C cooler than with the can on. I'd like to leave the can off until the end of the week so we can get a comparable data set for both the can on and off. Eventually I'll need to figure out a way to clamp the can down to the block in order to get better insulation and hopefully get even smaller temperature fluctuations.

Attachment 1: seis-temp-3.png
seis-temp-3.png
Attachment 2: seis-temp-full-2.png
seis-temp-full-2.png
  13883   Wed May 23 17:58:48 2018 gautamUpdateIOOMC1 Coil Driver pulled out
  • Marked up schematic + photo post changes uploaded to DCC page.
  • There was a capacitor in the DAQ monitor path making a 8kHz corner that I now removed (since the main point of this front panel HPF monitor point is to facilitate easy coil driver noise debugging, and I wanted to be able to use the SR785 out to high frequencies without accounting for an additional low pass). Transfer function from front panel LEMO input to front panel LEMO monitor is shown in Attachment #1.
  • Voltage noise measured at DB25 output (with the help of a breakout cable and SR560 G=100) with front panel LEMO input terminated to 50ohm, Bias input grounded, and pin1 of U21A grounded (i.e. watchdog enabled state) is shown in Attachment #2. This measurement was taken on the electronics bench.
  • Inside the lab (i.e. coil driver board plugged into eurocrate), the noise measured in the same way looks identical to what was measured in elog13870.
  • I tried repeating the measurement by powering the board using an bench power supply and grounding the bias input voltage near 1X6, and the strange noise profile persists. So this supports the hypothesis that some kind of environmental pickup is causing this noise profile. Needs more investigation. 

In any case, if it is indeed true that the optic sees this current noise, the place to make the measurement is probably the Sat. Box. Who knows what the pickup is over the ~15m of cable from 1X6 to the optic.

Quote:

Detailed report + photos to follow

 

Attachment 1: MC1_monitorTF.png
MC1_monitorTF.png
Attachment 2: MC1_ULnoise.pdf
MC1_ULnoise.pdf
  13885   Thu May 24 10:16:29 2018 gautamUpdateGeneralAll models on c1lsc frontend crashed

All models on the c1lsc front end were dead. Looking at slow trend data, looks like this happened ~6hours ago. I rebooted c1lsc and now all models are back up and running to their "nominal state".

Attachment 1: c1lsc_crashed.png
c1lsc_crashed.png
  13887   Thu May 24 15:18:12 2018 KiraUpdatePEMPID loop restarted

Rana said that it wasn't necessary to gather more data on the temperature fluctuations so I have reconnected the heater circuit and restarted the PID loop with the can on the seismometer.

  13888   Thu May 24 16:08:12 2018 KiraUpdatePEMparts list

We will need to order a few things for our final setup.

  1. 1U box to place the heater circuit and temperature circuits in. The minimum depth that will fit all the electronics is 10 inches according to my sketch.
    • I found two possibilities online for this. I don't know exactly what our budget is, but this one is $144. According to the datasheet, the front panel is less than 19 inches wide, so if we are to order this one, I've adjusted the width of the panel I designed to match the width of the panel that comes with it I've labeled it in the attached file as 1U-panel-1.
    • The other possibility is this one. It comes with handles already which is quite nice. I wasn't able to find a price for it on the website.
  2. Front panel for the 1U box and block panel. I've attached them as .fpd files below in one .zip file. Not sure if this is the correct way to attach them, though.
  3. We'll also need a 16 gauge cable that has 6 wires bunched together. This is to connect up the heater circuit and AD590s. The other cables that we will need can be found in the lab.
Attachment 1: front_panels.zip
  13893   Fri May 25 14:55:33 2018 Jon RichardsonUpdateCamerasStatus of GigE Camera Software Fixes

There is an effort to switch to an all-digital system for the GigE camera feeds similar to the one running at LLO, which uses Joe Betzwieser's custom SnapPy package to interface with the cameras in Python and aggregate their feeds into a fancy GUI. Joe's code is a SWIG-wrapping of the commercial camera-driver API, Pylon, from Basler. The wrapping allows the low-level camera driver methods to be called from within Python, and their feeds are forwarded to a gstreamer stream also initiated from within Python. The problem is that his wrapping (and the underlying Pylon software itself) is only runnable on an older version of Ubuntu. Efforts to run his software on newer distributions at the 40m have failed.

I'm working on a fix to essentially rewrite his high-level SnapPy code (generators of GUIs, etc.) to use the newest version of Pylon (pylon5) to interface at a low level with the cameras. I discovered that since the last attempt to digitize the camera system, Basler has released their own official version of a Python wrapping for Pylon on github (PyPylon).

Progress so far:

  • I've installed from source the newest version of Pylon, pylon5.0.12 on the SL7 machine (rossa). I chose that machine because LIGO is migrating to Scientific Linux, but I think this will also work for any distribution.
  • I've installed from source the the newest, official Python wrapping of the Basler Pylon software, pypylon.
  • I've tested the pypylon package and confirmed it can run our cameras.

The next and final step is to modify Joe's SnapPy package to import pypylon instead of his custom wrapping of an older version of the camera software, and update all of the Pylon calls to use the new methods. I'll hopefully get back to this early next week.

  13894   Tue May 29 16:22:43 2018 KiraUpdatePEMparts list

I've updated the parts list to be an excel document and included every single part we will need. This is ony a first draft so it will probably be updated in the future. I also made a mistake in hole sizing for the front panel so I've updated it and attached it as well (second attachment).

Edit: re-attached the EX can panel fpd file so that everything is in one place

Attachment 1: parts_list_-_Sheet1.pdf
parts_list_-_Sheet1.pdf
Attachment 2: 1U-panel-2.fpd
Attachment 3: EX-can-panel.fpd
  13895   Tue May 29 16:33:04 2018 SteveUpdatePEMair cond filters replaced

Chris replaced some air condition filters and ordered some replacement filter today.

Quote:

 

Quote:

 

Quote:

Yesterday morning was dusty. I wonder why?

The PRM sus damping was restored this morning.

Yesterday afternoon at 4 the dust count peaked 70,000 counts

Manasa's alergy was bad at the X-end yesterday. What is going on?

There was no wind and CES neighbors did not do anything.

Air cond filters checked by Chris. The 400 days plot show 3 bad peaks at 1-20, 2-5 & 2-19

 

  13896   Wed May 30 10:17:46 2018 gautamUpdateIOOMC1 Coil Driver pulled out

[rana,gautam]

Summary:

Last night, Rana fact-checked my story about the coil driver noise measurement. Conclusions:

  1. There is definitely pickup of strong lines (see Attachment #1. These are hypothesized to come from switching power supplies). Moreover, they breathe. Checkout Rana's twitter page for the video.
  2. The lines are almost (but not quite) at integer multiples of 19.5 kHz. The cause of this anharmonicity is to be puzzled out.
  3. When the coil driver board is located ~1m away from the SR785 and the bench supply powering it, even though the lines are visible in the spectrum, the low frequency shape does not show the weird broad features I reported here. The measured noise floor level is ~5nV/rtHz, which is consistent with LISO noise + SR560 input noise (see Attachment #2). However, there is still some excess noise at 100 Hz above what the LISO model leads us to expect. 
  4. The location of the coil driver board and SR560 relative to the SR785 and the bench power supply I used to power the coil driver board can increase the line heights by ~x50. 
  5. The above changes the shape of the low frequency part of the spectrum as well, and it looks more like what is reported in elog13870. The hypothesis is that the high frequency lines are downconverted in the SR560.

Note: All measurements were made with the fast input of the coil driver board terminated with 50ohms and bias input shorted to ground with a crocodile clip cable.

Next steps:

The first goal is to figure out where this pickup is happening, and if it is actually going to the optic. To this end, I will put a passive 100 kHz filter between the coil driver output and the preamp (Busby Box instead of SR560). By getting a clean measurement of the noise floor with the coil driver board in the Eurocrate (with the bias input driven), we can confirm that the optic isn't being buffeted by the excess coil driver noise. If we confirm that the excess noise is not a measurement artefact, we need to think about were the pickup is actually happening and come up with mitigation strategies.

RXA: good section EMI/RFI in Op Amp Applications handbook (2006) by Walt Jung. Also this page: http://www.electronicdesign.com/analog/what-was-noise

Attachment 1: EM_pickup.pdf
EM_pickup.pdf
Attachment 2: coilDriverNoiseComparison.pdf
coilDriverNoiseComparison.pdf
ELOG V3.1.3-