Brief Summary: I am currently looking at the acoustic noise around both arms to see if there are any frequencies from machinery around the lab that stand out and to see what we can remove/change. I am using a Bluebird microphone suspended with surgical tubing from the cable trays to isolate it from vibrations. I am also using a preamp and the SR875 spectrum analyzer taking 6 sets of data every 1.5 meters (0 to 200Hz, 200Hz to 400Hz, 400z to 800Hz, 800Hz to 3200Hz, 3.2kHz to 12kHz, 12kHz to 100kHz).

·                Attachment 1 is a PSD of the first 3 measurements (from 0 to 12kHz) that I took every 1.5 meters along the x arm with the preamp and spectrum analyzer

·                Attachment 2 is a blrms color map of the first 6 sets of data I took (from 2.4m to 9.9m) 

·                Attachmetn 3 is a picture of the microphone set up with the surgical tubing 

Problems that occurred: settings on the preamp made the first set of data I took significantly smaller than the data I took with the 0dB button off and the last problem I had was the spectrum analyzer reading only from -50 to -50 dBVpk

Going through the last ~20 hours of data, the MC1 sensor channels look glitch free the entire period. However, there is a ~10min period around 1PM UTC today when there were a couple of glitches ~80 counts in size in all the MC3 sensor channels. The attached shows the full 2k data from all 10 channels (MC1 and MC3 sensors) around this time.

Is this sufficient evidence to conclude that the Satellite boxes are to blame? It's hard to explain why the glitches come and go in this fashion, and also the apparent difference in the length of time for which the glitches persist. Here, in almost 24 hours, there is one incidence of glitching, but in yesterday's trend plot, the glitching remains present over several hours... The amplitude of the glitches, and their coincidence in all 5 channels, seems consistent with what we have been seeing though...

This was done by adding "Options +Indexes" to /etc/apache/sites-available/nodus

I've added a little more info about the apache configuration on the wiki: ApacheOnNodus

Might be. Or it might be in the satellite box cabling. Hard to tell without a tester. I recommend you squish the cables on there and lock the MC and get back to the usual business. I'll check on sat. box with Ben.

Both suspensions have been relatively well behaved for the best part of the last two days, since I effected the Satellite Box swap. Today morning, I set about re-enabling the damping and locking the MC. Judging by the wall StripTool, it stayed locked for about 30 mins or so, after which the glitching returned.

Attached is a screenshot of the sensor signals from MC1 and MC3 (second trend), and also the highest band (>30Hz) BLRMS output for the same 10 channels (full data sampled at 16Hz). Note that MC1 and MC3 satellite boxes remain swapped. So the glitches now have migrated to the MC3 channels.

I need to think about whether this is just coincidence, or if me re-enabling the damping has something to do with the re-occurrence of the glitching...

Addendum 4.30pm: I've also re-aligned the Y arm. Its alignment has been stable over the last few hours, despite several mode cleaner lock losses in between, it recovers good IR transmission. The X arm has been re-aligned to green, but I can't get it locked to the IR - everytime I turn the LSC to ETMX on, there seems to be some large misalignment applied to it. c1iscaux was dead, I restarted it by keying the crate. I haven't had time to investigate the X arm locking in detail, I will continue to debug this.

We should be able to connect to this station

Gautam and Steve,

It is hanging in the midle of the PSL enclosure. Wired to 1X1 to get plus and minus 15V through fuse.    It's output is connected to FB c17 input.

GV: C17 corresponds to "MIC 1" in the PEM model. So the output is saved as "C1:PEM-MIC_1_OUT_DQ"

Two day plot of glitching suspentions: MC3, ITMY and ETMX

On the control room monitors, I noticed that the IR TEM00 spot was moving around rather a lot in the Y arm. The last time this happened had something to do with the ETMY Oplev, so I took a look at the 30 day trend of the QPD sum, and saw that it was decaying steeply (Steve will update with a long term trend plot shortly). I noticed the RIN also seemed rather high, judging by how much the EPICS channel reading for the QPD sum was jumping around. Attached are the RIN spectra, taken with the OL spot well centered on the QPD and the arms locked to IR. Steve will swap the laser out if it is indeed the cluprit.

ETMY He/Ne 1103P  body temp is  ~45 C The laser was seated loosely  in the V-mount with black rubber padding.

The enclosure has a stinky plastic smell from this black plastic. This laser was installed on Oct 5, 2016 See 1 year plot.

Oplev servo turned off. Thermocouple attached to the He/Ne

It will be replaced tomorrow morning.

Summary:

I got around to doing this measurement today, using a minicircuits bi-directional coupler (ZFBDC20-61-HP-S+), along with some SMA-LEMO cables.

• With the IMC "well aligned" (MC transmission maximized, WFS control signals ~0), the RF power per quadrant into the Demod board is of the order of tens of pW up to a 100pW.
• With MC1 misaligned such that the MC transmission dropped by ~10%, the power per quadrant into the demod board is of the order of hundreds of pW.
• In both cases, the peak at 29.5MHz was well above the analyzer noise floor (>20dB for the smaller RF signals), which was all that was visible in the 1MHz span centered around 29.5 MHz (except for the side-lobes described later).
• There is anomalously large reflection from Quadrant 2 input to the Demod board for both WFS
• The LO levels are ~-12dBm, ~2dBm lower than the 10dBm that I gather is the recommended level from the AD831 datasheet

Details:

I first aligned the mode cleaner, and offloaded the DC offsets from the WFS servos.

The bi-directional coupler has 4 ports: Input, Output, Coupled forward RF and Coupled Reverse RF. I connected the LEMO going to the input of the Demod board to the Input, and connected the output of the coupler to the Demod board (via some SMA-LEMO adaptor cables). The two (20dB) coupled ports were connected to the Agilent spectrum analyzer, which have input impedance 50ohms and hence should be impedance matched to the coupled outputs. I set the analyzer to span 1MHz (29-30MHz), IF BW 30Hz, 0dB input attenuation. It was not necessary to turn on averaging to resolve the peaks at ~29.5MHz since the IF bandwidth was fine enough.

I took two sets of measurements, one with the IMC well aligned (I maximized the MC Trans as best as I could to ~15,000 cts), and one with a macroscopic misalignment to MC1 such that the MC Trans fell to 90% of its usual value (~13,500 cts). The peak function on the analyzer was used to read off the peak height in dBm. I then converted this to RF power, which is summarized in the table below. I did not account for the main line loss of the coupler, but according to the datasheet, the maximum value is 0.25dB so there numbers should be accurate to ~10% (so I'm really quoting more S.Fs than I should be).

For the well aligned measurement, there was ~0.4mW incident on WFS1, and ~0.3mW incident on WFS2 (measured with Ophir power meter, filter out).

I am not sure how to interpret the numbers for quadrants #2 and #6 in the first table, where the reverse coupled RF power was greater than the forward coupled RF power. But this measurement was repeatable, and even in the second table, the reverse coupled power from these quadrants are more than 10x the other quadrants. The peaks were also well above (>10dBm) the analyzer noise floor 

I haven't gone through the full misalginment -> Power coupled to TEM10 mode algebra to see if these numbers make sense, but assuming a photodetector responsivity of 0.8A/W, the product (P₁P₂) of the powers of the beating modes works out to ~tens of pW (for the IMC well aligned case), which seems reasonable as something like P₁~10uW, P₂ ~ 5uW would lead to P₁P₂~50pW. This discussion was based on me wrongly looking at numbers for the aLIGO WFS heads, and Koji pointed out that we have a much older generation here. I will try and find numbers for the version we have and update this discussion.

Misc:

1. For the sake of completeness, the LO levels are ~ -12.1dBm for both WFS demod boards (reflected coupling was negligible)
2. In the input signal coupled spectrum, there were side lobes (about 10dB lower than the central peak) at 29.44875 MHz and 29.52125 MHz (central peak at 29.485MHz) for all of the quadrants. These were not seen for the LO spectra.
3. Attached is a plot of the OSEM sensor signals during the time I misaligned MC1 (in both pitch and yaw approximately by equal amounts). Assuming 2V/mm for the OSEM calibration, the approximate misalignment was by ~10urad in each direction.
4. No IMC suspension glitching the whole time I was working today

System-wide CIT LDAS cluster maintenance may cause disruptions to summary pages today. 

Steve, Craig, Gautam

Today Steve replaced the ETMY He/Ne sr P919645 OpLev laser with sr P947049 and Craig realigned it using a new AR coated lenses.

Attached are the RIN of the OpLev QPD Sum channels.  The ETMY OpLev RIN is much lower than when Gautam took the same measurement yesterday.

Also attached are the pitch and yaw OLG TFs to ensure we still have acceptable phase margins at the UGF.

The last three plots show the optical layout of the ETMY OpLev, a QPD reflection blocker we added to the table, and green light to ETMY not being blocked by any changes to the OpLev.

This is probably just a confirmation of something we discussed a couple of weeks back, but I wanted to get more familiar with using the multi-coherence (using EricQs nice function from the pynoisesub package) as an indicator of how much feedforward noise cancellation can be achieved. In particular, in light of our newly improved WFS demod/whitening boards, I wanted to see if there was anything to be gained by adding the WFS to our current MCL feedforward topology.

I used a 1 hour data segment - the channels I looked at were the vertex seismometer (X,Y,Z) and the pitch and yaw signals of the two WFS, and the coherence of the uncorrelated part of these multiple witnesses with MCL. I tried a few combinations to see what is the theoretical best achievable subtraction:

1. Vertex seismometer X and Y channels - in the plot, this is "Seis only"
2. Seis + WFS 1 P & Y
3. Seis + WFS 2 P & Y
4. Seis + WFS 1 & 2 P
5. Seis + WFS 1 & 2 Y

The attached plot suggests that there is negligible benefit from adding the WFS in any combination to the MCL feedforward, at least from the point of view of theoretical achievable subtraction. 

I also wanted to put up a plot of the current FF filter performance, for which I collected 1 hour of data tonight with the FF on. While the feedforward does improve the MCL spectrum, I expected better performance judging by previous entries in the elog, which suggest that the FIR implementation almost saturates the achievable lower bound. The performance seems to have degraded particularly around 3Hz, despite the multi-coherence being near unity at these frequencies. Perhaps it is time to retrain the Weiner filter? I will also look into installation of the accelerometers on the MC2 chamber, which we have been wanting to do for a while now...

LDAS has not recovered from maintenance causing the pages to remain unavailable until further notice.

> System-wide CIT LDAS cluster maintenance may cause disruptions to summary pages today. 

                    Oct.  5, 2015              ETMY He/Ne replaced by 1103P, sr P919645,  made Dec 2014, after 2 years

                   Jan. 24, 2017              ETMY He/Ne replaced by 1103P,  sr P947049,  made Apr 2016,  after 477 hrs running hot

[gautam, lydia]

We rebooted c1psl, c1iscaux and c1aux which were all showing the typical symptom of responding to ping but not to telnet (and also blanked out epics fields on the MEDM screens). Keyed all these crates.

Restored burt snapshots for c1psl, PMC locked fine, and IMC is also locked now.

Johannes forgot to elog this yesterday, but he rebooted c1susaux following the usual procedure to avoid getting ITMX stuck. 

[Lydia, gautam]

To measure the modulation depth of the 29.5 MHz sideband, we plan to connect a bidirectional coupler between the EOM and the triple resonant circuit box. This will let us measure the power going into the EOM and the power in the reflection. According to the manual for the EOM (Newport 4064), the modulation depth is 13 mrad/V at a wavelength of 1000 nm. Before disconnecting these we will turn off the Marconi.

Hopefully we can be gentle enough that the EOM can be realigned without too much trouble. Before touching anything we'll measure the beam power before and after the EOM so we know what to match after.

If anyone has an objection to this plan, speak now or we will proceed tomorrow morning.

I'm afraid that the bidirectional coupler, designed to be 50ohm in/out, disturbs the resonant circuit designed for the EOM which is almost purely capacitive.

One possible way could be to measure the transfer function using the active FET probe from the triple resonant input to the output with the EOM attached.

Another way: How about to measure the reflection before the resonant circuit? Then, of course, there is the triple resonant interface circuit between the power combiner and the EOM. This case, we will see how much power is consumed in EOM and the resonant circuit. Then we can use the previous measurement to see the conversion factor between the power consumption to the modulation depth. Kiwamu may give us his measurement.

jiSome notes on the FSS configuration: ELOG 10321

Just collecting some links from my elog searching today here for easy reference later.

• EOM datasheet: Newfocus 4064 (according to this, the input Impedance is 10pF, and can handle up to 10W max input RF power).
• An elog thread with some past measurement details: elog 5339. According to this, the modulation depth at 29.5 MHz is 4mrad. The EOM's manual says 13mrad/V @1000nm, so we expect an input signal at 29.5MHz of 0.3V(pk?). But presumably there is some dependance of this coefficient on the actual modulation frequency, which I could not find in the manual. Also, Kiwamu's note (see next bullet) says that the EOM was measured to have a modulation depth of 8 mrad/V
• A 2015 update from Kiwamu on the triple resonant circuit: elog 11109. In this elog, there is also a link to quite a detailed note that Kiwamu wrote, based on his analysis of how to make this circuit better. I will go through this, perhaps we want to pursue installing a better triple resonant circuit...

I couldn't find any details of the actual measurement technique, though perhaps I just didn't look for the right keywords. But Koji's suggestion of measuring powers with the bi-directional coupler before the triple resonant circuit (but after the power combiner) should be straightforward. 

It was raised at the Wednesday meeting that I did not check the RF pickup levels while measuring the RF error signal levels into the Demod board. So I closed the PSL shutter, and re-did the measurement with the same measurement scheme. The detailed power levels (with no light incident on the WFS, so all RF pickup) is reported in the table below.

These numbers can be subtracted from the corresponding columns in the previous elog to get a more accurate estimate of the true RF error signal levels. Note that the abnormal behaviour of Quadrant #2 on both WFS demod boards persists.

The 3 pieces of Sapphire v-groove test cuts are back. They look good. The suspension wire 0.0017" ( 43 micron ) is show on some of the pictures.

Very nice! I got excited.

• Don't you ask Calum and co to check the groove size with their microscopes? Just give the samples and the wire.
• Do we want to make a simple "guitar" setup to measure the vibration Qs with Al piece, glass prism, ungrooved Sapphire, this grooved sapphire, grooved ruby, etc?

Rebooted c1iscaux, c1auxex and c1auxey which were all not reponding to telnet. The watchdogs for the ETMs were turned off and then I keyed all 3 crates. All slow machines are reponding to telnet now. Both green lasers locked to the arms so I didn't do any burt restore.

Just FYI I'm running a test of updated daqd code on fb1. 

fb1 has it's own fiber to the daq network switch, so nothing had to be modified to do this test. This *should* not affect anything in the rest of the system, but as we all know these are famous last words....  If something is going haywire, and you can't get in touch with me and can't figure what else to do, you can just log on to fb1 and shut it down.  It's not writing any data to any of the network filesystems.

The daqd code under test is from the latest advLigoRTS 3.2.1 tag, which has daqd stability fixes that will hopefully address the problems we were seeing last time I tried this upgrade.  We'll see...

I'm going to let it run over the weekend, and will check in periodically.

"Why does the word wrapping not work in our browsers with ELOG?" I sometimes wonder. Some of the elogs are fine, but often the 40m one has the text run off the page.

I found that this is due to people uploading HUGE images. If you need to do this, just use the shrink feature in the elog compose window so that we only have to see the thumbnail at first. Otherwise your 12 MP images will make it hard to read everyone else's entries.

I'm not sure if this is related, but since today morning, I've noticed that the data concentrator errors have returned. Looking at daqd.log, there is a 1 second timing mismatch error that is being generated. Usually, manually running ntpdate on the front ends fixes this problem, but it did not work today.

The coil and PD BLRMS are useful tools in identifying when glitches occur in the PD  readout, I thought it would be good to install them for ITMY, ETMX and SRM (since I plan to switch the MC3 satellite box, which we suspect to be problematic, with the SRM one). For this purpose, I had to install some IPC SHMEM blocks in C1SUS and recompile. 24 IPC channels were added to pipe the coil, PD and Oplev signals from C1SUS to C1PEM - the recompilation went smoothly, and it doesn't look like the model computation time has increased significantly or that the model is any closer to timing out.

However, I was unable to install the BLRMS blocks in C1PEM, as when I tried to compile the model with BLRMS for these extra 24 channels, I got a compilation error saying that I have exceeded the maximum allowed 499 testpoints per channel. Is there any workaround to this? It would be possible to create a custom BLRMS block that doesn't have all those testpoints, maybe this is the way to go? Especially if we want to install these channels for all our SOS optics, and also replace the current Seismic BLRMS with this scheme for consistency?

GV edit: I have implemented this scheme - after backing up the original BLRMS_2k part, I made a new one with no testpoints and only EPICS readouts. Doing so allowed me to recompile c1pem without any issues, the CPU time seems to have gone up by 3us from ~55us to 58us. So the BLRMS data record is only available at 16Hz, since there are no DQ channels in the BRLMS block - do we want these in any case? Let's see how this does over the weekend...

[gautam, Lydia]

We set out to measure the 29.5 MHz power going to the EOM today but decided to start by looking at the output of the RF AM stabilizer box first. We wanted to measure the AM noise with a mixer, so we needed to know the power it was giving. We looked at the ouput that goes to the power combiner on the PSL table and found it was putting out only -2.0 dBm (~0.5 Vpp)! This was measured by taking a spectrum with the AG4395 and confirmed by looking on a scope.

To find out if this could be adjusted, we found an old MEDM screen (/opt/rtcds/caltech/c1/medm/c1lsc/master/C1LSC_RFADJUST.adl) and moved the 29.5 MHz EOM Mod Index Adjust slider while measuring the voltage coming in to the MOD CONTOL connection on the front of the AM stabilizer box. Moving the slider from 0 to 10 changes the input voltage linearly from -10 V to 10 V measured with a DMM at the cross-connects as we couldn't find an appropriate adapter for the LEMO cable. The 29.5 MHz modulation only appeared for slider values between 0 and 5, after which it abruptly shuts off. However, changing the slider value between 0 and 5 (Voltage from -10 to 0) does not change the amplitude of the output.

This seems like a problem; further investigation into the AM stabilizer box is neccessary. This DCC document outlines how to test the box, but we can't find a schematic. Since we don't have any mixers that can handle signals as small as -2 dBm, we gave up trying to measure the AM noise and will attempt to measure that and the reflection power from the EOM + resonant circuit once this problem has been diagnosed and fixed.

GV: After some digging, I found the schematic for the RF AM stabilization box (updated wiki and added it to the 40m document tree). According to it, there should be up to +22dBm of RF AM stabilized output to the EOM available, though we measured -2dBm yesterday, and could not vary this level by adjusting the EPICS voltage value. Neglecting losses in the cabling and the power combiner on the PSL, this translates to a paltry 0.178Vrms*0.6*8mard/Vrms ~ 0.85 mrad of modulation depth (gain at 29.5 MHz of the triple resonant circuit taken from this elog)... I think we need to pull this 1U chassis out and debug more thoroughly...

Some more details of our investigation:

1. Here is a spectrum of the signal to the power combiner on the PSL table, measured on the output of the RF AM Stabilization box.
   
   Perhaps these sidebands were the ones I observed while looking at the input to the WFS demod board.
2. The signal looked like a clean sinusoid when viewed on an oscilloscope with input impedance set to 50ohms. There were no sharp features or glitches in the time we observed, except when the 29.5 MHz MEDM slider was increased beyond 5, as noted by Lydia.
3. We couldn't find a schematic for this RF AM Stabilization servo, so we are not sure what RF output power to the EOM we should expect. Schematic has since been found.
4. I measured the power level at the input side (i.e. from the crystal) and found that it is ~12dBm, which seems reasonable (the front panel of the box housing the 29.5 MHz oscillator is labelled 13dBm). The schematic for the RF AM stabilization box says we should expect +10dBm at the input side, so all this points to a problem in the RF AM stabilization circuit...
5. There is an attenuator dial on the front panel of the said RF AM stabilization servo that allows one to tune the power to the LO input of the WFS. Right now, it is set to approximately 7dB of attentuation, which corresponds to -12dBm at the WFS demod board input. I did a quick check to see if turning the dial changed the signal level at the LO input of the WFS board. The dial moves in clicks of 1dB, and the RF power at the LO input of the demod board increased/decreased by ~1dBm for each click the dial was rotated (I only explored the region 3dB-11dB of atttentuation). So it should be possible to increase the LO level to the WFS demod boards, is there any reason we shouldn't increase this to -8bBm (~0.25Vpp into 50ohms, which is around the level Koji verified the mixer to be working well at)?
6. There were a couple of short ribbon cables which were just lying around on top of the cards in the eurocrate, Koji tells me that these were used as tester cables for checking the whitening filters and that they don't serve any purpose now. These have been removed.
7. Added a button to IMC MEDM screen to allow easy access to the MEDM screen with slider to control the 29.5MHz modulation depth - though as mentioned in Lydia's elog, at the moment, this slider has no effect on the 29.5MHz power level to the EOM...
   

If this problem started before ~4pm on Friday then it's probably unrelated, since I didn't start any of these tests until after that.  If unexplained problem persist then we can try shutting of the fb1 daqd and see if that helps.

I just aborted the fb1 test and reverted everything to the nominal configuration.  Everything looks to be operating nominally.  Front ends are mostly green except for c1rfm and c1asx which are currently not being acquired by the DAQ, and an unknown IPC error with c1daf.  Please let me know if any unusual problems are encountered.

The behavior of daqd on fb1 with the latest release (3.2.1) was not improved.  After turning on the full pipe it was back to crashing every 10 minutes or so when the full and second trend frames were being written out.  lame.  back to the drawing board...

[johannes, gautam]

We pulled out the RF AM stabilization box from the 1X2 rack. PSL shutter was closed, marconi output, RF distribution box and RF AM stabilization box were turned off in that order. We had to remove the 4 rack nut screws on the RF distribution box because of the stiff cables which prevented the RF AM stabilization box extraction. I've left the marconi output and the RF distribution boxes off, and have terminated all open SMA connections with 50 ohm terminators just in case. Rack nuts for RF distribution box have been removed, it is currently sitting on a metal plate that is itself screwed onto the rack. I deemed this a stable enough ledge for the box to sit on in the short run, while we debug the RF AM stabilization box. We will work on the debugging and re-install the box as soon as we are done...

[gautam, Lydia]

We looked at the RF AM stabilizer box to see if we could find out 1) Why the output power is so low, and 2) Why it can't be changed with the DC input "MOD CONT IN." Details to follow, attached is the annotated schematic from DCC document D000037. 

We are not returning the box tonight so the PSL shutter remains closed. 

1. What is the probe situation? Ought to use a high impedance FET probe to measure this or else the scope would load the circuit.
2. The ERA amplifiers are known to slowly die over ~10 year times scales. Search our ELOG for ERA-5. We'll have to replace some; ask Steve to order if we don't have many in the Plateau Tournant.
3. What kind of HELA are the HELA amplifiers? Please a link to the data sheet if you can find it. I wonder what the gain and NF are at 30 MHz. I think the HELA-10D should be a good variant.

I think this cron job is running on NODUS (our gateway) instead of our scripts machine:

*/1 * * * * /opt/rtcds/caltech/c1/scripts/Admin/n2Check.sh >> /opt/rtcds/caltech/c1/scripts/Admin/n2Check.log 2>&1

moreover this script has a 90MB log file full of not finding its channel

I wish this script was in python instead of BASH and I wish it would run on megatron instead of nodus (why can't megatron send us email too?) and I wish that this log file would get wiped out once in awhile. Currently its been spitting out errors since at least a month ago:

Tue Jan 31 14:10:02 PST 2017 : N2 Pressure:

Channel connect timed out: 'C1:Vac-N2pres' not found.

(standard_in) 1: syntax error

> What is the probe situation? Ought to use a high impedance FET probe to measure this or else the scope would load the circuit.

We did indeed use the active probe, with the 100:1 attenuator in place. The values Lydia has quoted have 40dB added to account for this.

> What kind of HELA are the HELA amplifiers? Please a link to the data sheet if you can find it. I wonder what the gain and NF are at 30 MHz. I think the HELA-10D should be a good variant

The HELA is marked as HELA-10. It doesn't have the '+' suffix but according to the datasheet, it seems like it is just not RoHS compliant. It isn't indicated which of the varieties (A-D) is used either on the schematic or the IC, only B and D are 50ohms. For all of them, the typical gain is 11-12dB, and NF of 3.5dB.

A novice was learning at the feet of Master Daqd. At the end of the lesson he looked through his notes and said, “Master, I have a few questions. May I ask them?”

Master Daqd nodded.

"Do we record minute trends of our data?"

"Yes, we record raw minute trends in /frames/trend/minute_raw"

"I see. Do we back up minute trends?"

"Yes, we back up all frames present in /frames/trend/minute"

"Wait, this means we are not recording our current trends! What is the reason for the existence of seperate minute and minute_raw trends?

“The knowledge you seek can be answered only by the gods.”

"Can we resume recording the minute trends?"

Master Daqd nodded, turned, and threw himself off the railing, falling to his death on the rocks below.

Upon seeing this, the novice was enlightened. He proceeded to investigate how to convert raw minute trends to minute trends so that historical records could be preserved, and precisely when Master Daqd started throwing himself off the mountain when asked to record minute trends.

Someone installed "Debian" on allegra. Why? Dataviewer doesn't work on there. Is there some advantage to making this thing have a different OS than the others? Any objections to going back to Ubuntu12?

I've been suggesting that there may be something wonky with the Seismic Rainbow Striptool on the wall for the last couple of weeks. Here are a few things that were verified today.

1. If you want to restore the StripTools in the control room, just run /opt/rtcds/caltech/c1/scripts/general/startStrip.sh. I have verified as of today that this works, and in future, any changes to channels/limits/colors of traces etc should be reflected in this script.
2. Though some of the BLRMS bands have looked anomalous over the last few weeks, in particular the 0.3-1Hz band. The attached 120 day trend plot suggests that there hasn't been any dramatic change recently. In fact, looking on the summary pages, Rana noticed that today was an unusually low 0.3-1Hz activity day..

My elog negligence punchcard is getting pretty full... It's pretty much for the same reason as using Debian for optimus; much of the workstation software is getting packaged for Debian, which could offload our need for setting things up in a custom 40m way. Hacking the debian-focused software.ligo.org repos into Ubuntu has caused me headaches in the past. Allegra wasn't being used often, so I figured it was a good test bed for trying things out.

The dataviewer issue was dataviewer's inability to pull the `fb` out of `fb:8088` in the NDSSERVER env variable. I made a quick fix for it in the dataviewer launching script, but there is probably a better way to do it.

I've added the schematic of the RF AM stabilization board to the 40m PSL document tree, after having created a new DCC document for our 40m edits. Pictures of the board before and after modification will also be uploaded here...

I made a crude sketch for how Lydia and I envision the connector situation on the back of the vme crates to be solved. Essentially the side panels of each crate extend about 2" (52 mm) beyond the edge of the DIN connectors. This is plenty of space for a simple PCB board. The connector of choice is D-Sub. We can split the 64 used pins into 2x 37 D-Sub OR (2x25 pin + 1x15pin). The former has fewer cables, but a few excess unused leads. A quick google search showed me that it is much cheaper to get twisted pair cables for 15 and 25 pin D-Subs. From what I remember, the used pins on the DIN connectors are concentrated on the low numbers end and the high numbers end, so might not need the 'middle' connector in many cases if we decide to break it up into three. I have to check this with Lydia though.

The D-Sub connectors would be panel mounted, for which we need a narrow panel piece with dsub cutouts. We can run horizontal struts across the vme crate from side panel to side panel. This way the force upon cable (dis)connection is mostly on the panel which is attached to the struts which are attached to the crate. This will also prevent gravitational sag or cable strain from pulling on the DIN connection, and we can use twisted pair cables with backshell, screws, and strain reliefs.

I was lookng into getting started with the PCB when Altium complained that the license is expired and to renew it. This is a relatively simple board layout so some free software out there is probably enough.

[rana, gautam, lydia]

Today we looked at the schematics for the RF AM stabilizer box and decided that there were an unnecessary amount of attenuators and amplifiers cancelling each other out and adding noise. At the end of the path are 2 HELA-10D amplifiers which we guessed based on the plots for the B version would have an acceptable amount of compression if the output of the second one is ~27dBm. This means the input to the first one should be a few dBm. This should be achieved with as simple a path as possible.

This begged the question, do we need the amplitude to be stabilized at all? Maybe it's good enough already when it comes into this box from the RF distribution box. So I tried to measure the AM noise of the 29.5 MHz signal that usually goes into the AM stabilizer:

• I first measured the power to be 12.8 dBm with the AG4395.
• I sent the signal through a splitter, then sent one side attenuated by 3 dB to the LO side of a level 7 mixer, and the other side attenuated by 10 dB to the RF side of the mixer.
• The output of the mixer went through a lowpass filter at 1.9 MHz (with a 50Ω inline terminator). Initially I connected this directly to a DAQ channel (C1:ALS-FC_X_F_IN), but the ADC noise was stronger than the AM signal.
• To fix this I used the SR560, AC coupled with a gain of 10^4. Attachment 1 is a spectrum of the noise measured with everything connected as described, and also for separate portions of the signal chain:
  • I measured the ADC noise by connecting a terminator to the cable going to DAQ.
  • I measured the mixer noise by putting a terminator on the RF input (and the end of the cable that was connected to it), while still driving LO.
  • I measured the SR560 noise by putting a terminator on the input.

It seems like I'm getting mostly noise from the SR560. Maybe it would be better to use an SR785 to take data instead of DAQ, and then skip the SR560? At low frequencies it seems like the AM noise measurement may be actually meaningful. In any case, if the actual AM noise from the crystal is lower than any of these other noise sources, it means we probably don't need to stabilize the amplitude with a servo, which means we can simplify the AM stabilizer board considerably to just amplify what it gets to 27 dBm.

For a comparison: OMC ELOG 238

Here's what I'm planning to do to the RF AM stabilizer box. I'm going to take out several of the components along the path to the EOM (comments in green), including the dead ERA-4 and ERA-5 amplifiers, the variable attenuator which is controlled by a switch that can't be accessed outside the box, and the feedback path from the daughter board servo. I'm arranging things so that the output of the HELA-10 does not exceed the maximum output power. 

I wasn't quite as sure what to do about the path to the ASC box (comments in blue). I talked with Gautam and he said this gets split equally between several singals, one of which goes to the LO of the demod board which expects -10 dBm and currently gets -12 dBm (can go up to -8 by turning switch). So maybe we don't actually want the signal to be anywhere near +27 dBm at the output. The plans for the box are here, it looks like +27 in will end up with +10 at each output, which is way more than what's currently coming out. But maybe this needs to be increased to match the other path? 

Also we haven't measured the actual response of the variable attenuator U4 for various switch positions; it's the same model as the one I'm removing from the EOM path and that one had slightly different behavior for different switch positions than what the spec sheet says. Same goes for the HELA-10 units along this path: what is their actual gain? So perhaps these should be measured and then a single attenuator should be chosen to get the right output signal level. Alternatively it could just be left alone, if it is at an OK level right now. Advice on what to do here would be appreciated.  

I'll work on the EOM path tonight and wait for feedback on the rest of it. 

EDIT: Gautam pointed out that there's some insertion loss from the components I'll be removing that hasn't been accounted for. Also the plans have been updated to reflect that I'm replacing AT5 with a 1dB attenuator (from 6 dB). 

I suggest:

1. Disable the path which goes to the two spare outputs. Replace the ERA-5 with a 50 Ohm resistor to terminate that path. Make sure the ERA bias voltage is not shorting into something.
2. Remove the ERA amps from the ASC path and remove the switch. Make it fixed gain such that we get +27 dBm out of the front.
3. Put the ASC output into the 1U multi-splitter box and attenuate those outputs so that they supply ~0 dBm to the 2 WFS and the LSC Demod board.

I think this then allows us to have the low noise OCXO signals everywhere with enough oomph.

I made some of the changes. Gautam and I will finish tomorrow. 

While I was soldering the sharpest tip of the soldering iron (the one whose power supply shows the temperature) stopped working and I switched to a different one. Not sure how to fix this. 

Do we want to replace all of the removed ERA's with 50 Ohm resistors, or just the one along the spare output path? I shorted one of them with a piece of wire and left all the others open. 

I couldn't get one of the attenuators off (AT1, at beginning of ASC path). In trying I messed up the solder pad. Part of the connecting trace on the PCB board is exposed so we should be able to fix it. 

FYI this issue has still not been solved, but the pages are working because I got the software running on an
alternative headnode (pcdev2). This may cause unexpected behavior (or not).

> LDAS has not recovered from maintenance causing the pages to remain unavailable until further notice.
> 
> > System-wide CIT LDAS cluster maintenance may cause disruptions to summary pages today.