It seems that FSS slow servo stopped working.

I found that megatron was restarted (by Rana, to finish an apt-get upgrade) on ~18:47 PDT today.

controls@megatron|~> last -5
controls pts/0        192.168.113.216  Mon May 15 19:15   still logged in   
controls pts/0        192.168.113.216  Mon May 15 19:14 - 19:15  (00:01)    
reboot   system boot  3.2.0-126-generi Mon May 15 18:50 - 19:19  (00:29)    
controls pts/0        192.168.113.200  Mon May 15 18:43 - down   (00:04)    
controls pts/0        192.168.113.200  Mon May 15 15:25 - 17:38  (02:12)

FSSslow / MCautolocker were restarted on megatron.

As part of investigation into this issue, Jonathan Hanks pointed out that the "minute trends" being recorded by our system were actually only being recorded every 120 seconds (a.k.a. 2 minutes). He had fixed the appropriate line in the parameter file, but had not restarted the FW processes. I had restarted it on Friday. (but failed to elog it !) 

To check if this made any difference, I pulled 1 hour of "minute trend" data for the PSL table temperature channel from ~1 hour ago, and compared the number of datapoints against a 1 hour minute trend time series from 2 May. I've put the display with # of datapoints (for an identical length of time) from before [left] and after [right] the restart next to the plots in Attachment #1. Seems like we are getting minute trends written every 60 seconds now, as it should be .

The unavailability of trends from nodus is a separate issue for which JH has suggested another fix, to be elogged separately.

I have to blame Jamie for putting extra 2 randomly.
Measured PRM-PR2 cavity finesse was actually 108 +/- 3 (even if you use digital system to get data).

Lorentzian fit:
  Lorentzian function is;

f(x;x0,gamma,A) = A * gamma**2/((x-x0)**2+gamma**2)

  where x0 is the location of the peak, gamma is HWHM, and A is the peak height.
  Lorentzian fitting function in my original code (/users/yuta/scripts/modescanresults/analyzemodescan.py) was

fitFunc = lambda p,x,m: (m-p[2])*p[0]**4/(4*(x-p[1])**2+p[0]**4)+p[2]

  In this function, p[0] is sqrt(FWHM), not sqrt(HWHM). I doubled gamma to make it FWHM and squared it because they should be positive.
  During Jamie's modification of my code, he doubled p[0]**2 to get FWHM, which is wrong (/users/jrollins/modescan/modescan.py).

  I should have commented that p[0] is sqrt(FWHM).

Redoing the analysis:
  1. I pulled 2 out, and modified Jamie's modescan.py so that you can name each peak with peakdistinguish=True option. I also modified fitpeak function so that it throws away "peaks" which don't look like a peak.

  2. If you run /users/yuta/PRCmodescan/run.py and name each peak, you will get peaks.csv which includes peak position, FWHM, and the type of the peak;

0.065017,0.001458,l
0.070446,0.001463,3
0.075940,0.001509,2
0.081552,0.001526,1
0.087273,0.001565,0
0.112027,0.001911,u
0.278660,0.002211,u
0.306486,0.001658,0
0.312480,0.001576,1
0.313626,2.507910,
0.318486,0.001626,2
0.319730,2.633097,
0.324801,0.001739,3
0.331848,0.001922,l
0.527509,0.001603,l
0.533231,0.001445,3
0.538648,0.001488,2
0.544081,0.001455,1
0.549517,0.001498,0
0.551725,2.422759,
0.570972,0.001346,u

  3. /users/yuta/PRCmodescan/calcmodescanresults.py reads peaks.csv and tells you the results;

Time between TEM00 and sideband  0.0239435  pm  0.00115999887452  sec
Calibration factor is  462.167602898  pm  22.3907907867  MHz/sec
FSR is  78.4797010471  MHz
FWHM is  0.729828720682  pm  0.0174145743828  MHz
TMS is  2.64718671684  pm  0.0538858477824  MHz
Finesse is  107.53166986  pm  2.5658325169
Cavity g-factor is  0.994390582331  pm  0.000228155661075
Cavity g-factor is  0.988812630228  pm  0.000453751681357   (Edited by YM; see elog #8056)
RoC of PR2 is  -187.384503001  pm  4.26100999578  m (assuming PRM RoC= 122.1  m)
RoC of PRM is  217.915890722  pm  5.65451518991  m (assuming PR2 RoC= -600  m)

I've spent an inordinate amount of time trying to figure out how to get pianosa to support dual monitors.  It apparently has some special nvidia graphics that are not well supported in Ubuntu (10.04 at least).  I've tried installing a newer kernel (3.0.0) and installing the special nvidia compile-from-source Ubuntu packages, but nothing is working.  And now unfortunately he's not giving me any video at all.  I'm sick of this today, so I'll try again tomorrow.

In the future we should avoid these bullshit nvidia cards like the plague.

I managed to get pianosa working again with just a single monitor.  I'm done trying to configure it for dual, though.

[Jamie, JC, Chris]

Today we made a failed attempt to take over the 40m hardware with the new front ends on the test stand.

As an initial test, we connected the new c1iscey to its I/O chassis using the OneStop fiber link. This went smoothly, so we tried to proceed with the rest of the system, which uncovered several problems. Consequently, we’ve reverted control back to the old front ends tonight, and will regroup and make another attempt tomorrow.

Status summary:

• c1iscey worked on the first try
• c1lsc worked, after we sorted out which of the two OneStop cables run to its rack we needed to use
• c1sus2 sort of worked (its models have been crashing sporadically)
• c1ioo had a busted OneStop cable, and worked after that was replaced
• c1sus refused to work with the fiber OneStop cables (we tried several, including the known working one from c1ioo), but we jury-rigged it to run over a copper cable, after nudging the teststand rack a bit closer to the chassis
• c1iscex refused to work with the fiber OneStop cables, and substituting copper was not an option, so we were stuck

There are various pathologies that we've seen with the OneStop interface cards in the I/O chassis. We don't seem to have the documentation for these cards, but our interpretive guesses are as follows:

• When working, it is supposed to illuminate all the green LEDs along the top of the card, and the four next to the connector. In this state, you can run lspci -vt on the host, and see the various PLX/Contec/etc devices that populate the chassis.
• When the cable is unplugged or bad, only four green LEDs illuminate on the card, and none by the connector. No devices from the chassis can be seen from the host.
• On c1iscex and c1sus, when a fiber link is plugged in, it turns on all the LEDs along the top of the card, but the four next to the connector remain dark. We’re not sure yet what this is trying to tell us, but lspci finds no devices from the chassis, same as if it is unplugged.
• Also, sometimes on c1iscex, no LEDs would illuminate at all (possibly the card was not seated properly).

Tomorrow, we plan to swap out the c1iscex I/O chassis for the one in the test stand, and see if that lets us get the full system up and running.

I assume it's because the burt restore didn't work for the SUS summary screen, but all of the values for the ifo suspensions (not the MCs...they're okay) are red. 

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

 My guess is that this has something to do with the NDS client version you're using.  Try running the script on a machine where pynds and nds-client are known to be compatible, like pianosa.

 Doesn't work on pianosa either. Has someone changed the python environment?

pianosa:SUS_SUMMARY 0> ./setSensors.py 1000123215 600 0.1 0.25
Traceback (most recent call last):
  File "./setSensors.py", line 2, in <module>
    import nds
ImportError: No module named nds

Chub mentioned to Paco and I that the Nitrogen seemed to be losing pressure quicker than usual. After looking over the previous 4 months on Dataviewer, the pressure has a pretty consistent slope. I have ran into the issue of the neck of the N2 tank slighty leaking, so this may have been the issue. For now, there does not seem to be any significant or obvious problem.

Zach and Koji

The old small MMT was removed and wrapped by Al foils.

The steering mirror IM2-IM4 were displaced and aligned.

The Faraday isolator block is moved and aligned.

The MC is realigned and resonatng TEM-00.

Now the MC has slightly miscentered beam on the mirrors owing to change of the stack leveling.
OSEMs are also in a strange state. We should check this later.

 Neither of these computers were listed in the Martian Host Table in the wiki, so I put them on there.  It's handy to keep this updated, so that we know what IP addresses are available.

(Kiwamu, Yuta)

Symptom:
 Farfalla(Acer Aspire one KAV60 netbook) couldn't run Firefox and returned the following error:
  Error: platform version '1.9.2.8' is not compatible with
  minVersion >= 1.9.2.9
  maxVersion <= 1.9.2.9

What we did:
1. Added the following line to ~/.cshrc.
  alias firefox "/usr/lib/firefox-3.6/firefox"
2. Made a cool launcher for firefox.

Result:
 Farfalla can fly into the web with Firefox now.

Notes:
 Even if it was then before, bash could run firefox. tsch couldn't.
 The command firefox was /cvs/cds/caltech/apps/linux/bin/firefox for tsch, because of the source /cvs/cds/caltech/cshrc.40m.
 I did this to zita which had the same symptom, too.

Next work:
 Farfalla wakes up on the wrong side of the bed. This has to be fixed.

A few years ago, Koji and I setup a delay line phase shifter, which can be used to impart a (switchable) delay to a signal path. Since we talked about reviving the fast (= high bandwidth) ALS control scheme at the meeting, I reminded myself of the infrastructure available.

• Schematic
• Comprehensive note on theory of operation / performance.
• Past elog threads - #11603 and #11604.
• Attachment #1 - my modification to the ALS screen to add a slider that controls the channel C1:LSC-BO_1_0_SET. The label is a bit misleading for now - elog11604 tells you the conversion between this slider value and the actual delay in nanoseconds, but I couldn't get a soft channel set up that correctly FLNKed to this record. In the process of trying to do so, I edited the C1_ISC-AUX_ALS.db file, and also restarted the modbus and latch processes on c1iscaux a few times.
• Attachment #2 - frequency dependent loss for some representative delays. At ~200 MHz, I find the measured loss to be > 8dB, which is ~2dB more than what the D. Sigg note tells me to expect. This is rather a lot of loss, but I guess it's okay. Measurement cable loss was calibrated out with the AG4395A.
• Attachment #3 - confirmation of constantness of delay as a function of frequency, for some representative delays. The "undelayed" setting corresponds to a fixed delay of ~4 nsec, which is consistent with what the D. Sigg note tells me to expect. Once again, I calibrated out the delay of the measurement setup using the AG4395A.

For a beat note in the regime 10-100 MHz, we should have plenty of range in this module to add a delay such that we zero one quadrature of the ALS DFD output (for a linear error signal). 

I then proceeded to connect the single-ended front panel BNC corresponding to the ALS_X_I DFD channel to the IN2 input of the CM board (this would be what we use for high bandwidth ALS feedback). The conventional ALS system uses the differential output from a rear-panel D-sub, so in principle, both systems could run in parallel. I confirmed that I could see a signal when the IN2 path on the CM board was engaged (monitored using ndscope at the CM_Slow output), and that this signal stabilized when the green laser was locked to the X-arm length, which itself was slaved to the PSL frequency using the usual POX locking scheme. I have not yet routed the LO leg of the ALS_X beat through the delay line phase shifter - see next elog for details.

Update about the ALS MEDM screen slider: the trick was to change the OMSL field of the C1:LSC-BO_1_0 channel to "closed_loop" instead of "supervisory". Once this is done, the DOL value of the same channel can be set to the soft channel C1:ALS-DelayCalc, which sets the 16 bit binary string that controls the delay. Because arbitrary delays are not possible, I think it's more natural for the user to interact with this 16-bit binary string rather than the actual delay itself. So the MEDM screen has been slightly modified from what is shown in Attachment #1.

In the process of setting up some cabling at 1Y2, I must've bumped a cable to the c1lsc expansion chassis. Anyways, the c1lsc models crashed. I ran the reboot script around 530pm PDT. Usual locking behavior was recovered after this. The work at 1Y2 was:

• Ran a cable from X Beat power splitter ("LO" leg of the analog delay line) to variable delay line. 
• Ran cable from delay line to demodulator's LO input.
• Set up the SR785 for some CM board TF measurements.

The IN2 to CM board was already connected to I single ended output of the ALS X demodulator. The ~100 Hz UGF digital locking using the CM_SLOW path is straightforward but I didn't have any success with the AO path tonight. I wonder how high BW this lock can be made without injecting a ton of noise into the IMC loop, given that the EX uPDH only has ~ 10 kHz UGF.

Attachment #1 shows the spectra of the ALS signal 

• The two "CM Slow" traces are the digitized "SLOW" output of the common mode board, whose IN2 is connected to the demodulated I output of the analog delay line.
• The delay in the LO line of the analog delay line is adjusted to zero the DC value of this signal to best effort.
• These spectra are measured with the arm cavities POX/POY locked, and the EX laser locked to the arm cavity using the end PDH box.
• I simultaneously monitor the output of the digital phase tracker servo, and scale the CM Slow signal such that the spectra line up. The scaling factor required was to multiply the CM_SLOW signal x10 (CM board IN2 gain was set to +6dB, to account for the x2 gain in going from single ended to differential inside the ALS demodulator box).
• One puzzline feature is why switching on the ADC whitening makes the ALS spectrum noisier (even though it clearly changes the digitization noise floor). There is a peak that appears at ~ 8 kHz with the whitening on, and it may also be downconverted noise from some peak at higher frequencies I guess (if the AA isn't sharp enough). 

Attachment #2 is an OLTF measurement.

• In the blue trace, the arm length is controlled by using the CM Slow signal as an error signal, applying feedback to IMC length via MC2.
• In the red trace, I turned the digital MC2 violin notches off, and added upped the IMC IN2 gain to -12 dB (AO gain slider = 0dB).
• This was as high as I could go before the PC drive RMS began to go crazy.
• But still, there isn't any significant phase advance.
• It is possible I need to tack on a low-pass filter to prevent noise injection at higher frequencies...

I've made a cascaded passive 2-pole pomona box for fast ALS use, using LISO to check that it'll give the right shape when hooked up to the CM board's input stage. 

First stage is a 133Ohm + 10uF cap for ~120Hz LP, second is 1.15kOhm + 47nF cap for ~3.8kHz LP. The DC gain is ~0.75, which is much better than what I was doing before. The second stage would normally make a 2.9kHz LPF on its own, but the loading of the input stage moves the corner up. 

It seems the 133 Ohm resistor is a reasonable load on the output AD829 of the ALS demod board (short-circuit output current of 32mA and a series output resistor of 499Ohm). To be able to use the digitized ALSX I and the lowpassed analog version simultaneously, I had to buffer the signal with a SR560 before the pomona box, otherwise the signals looked distorted. This isn't a good long-term solution. Maybe I can used the further-buffered differential output to drive the LPF+CM board. 

The LISO files used to model the filter and CM board input stage, and fit the pole frequencies are attached. 

I made some attempts to get the AO path going today, but I suspect this daytime noise is just too much; the PC drive seems too irritable

I've been using an SR560 to experiment with differnent pole frequencies, to try and cancel the mystery zero. It's after the ALS demod board, before the pomona LPF with a gain of five. 

A pole frequency of 3kHz seems to recover sensible loop shapes. I've been able to crossover the AO path to make a nice long phase bubble which isn't the prettiest, but seems workable.

Getting to this point is now almost entirely scripted and repeatable; one just has to make sure that the ALS beat has the correct sign and adjust the delay line length. Most frustratingly, due to the dependence of the ALS gain on beat frequency / magnitude / delay, which can all vary on the order of a few dB, the AO gain settings to get to the crossed over point are not always the same, so at the end it's a lot of small steps and frequent loop measurements. 

The FSS crossover and overall IMC loop gain have to be pretty actively managed too. It's all too easy to drive the pockel's cell crazy. And if it's going crazy on its own anyways, there's no hope in trying to pile ALS sensing noise on top of it... It would really help in this effort to fix the whole PC situation up. 

Unfortunately, lock is lost when increasing the overall gain on the common mode board even by 1dB. We've seen in the single arm tests, that the gain settings have an appreciable difference in offset between them. Maybe this step is more than what the loop can handle? Or maybe it's the voltage glitches... Maybe some gain reallocation can put me on a region of the slider that glitches less.

In terms of the mystery plant features, I figure I'd like to take the analog TF of AO control signal to, say, AS55, and see what may or may not be there. I just haven't done this tonight since it would involve recabling the analyzer, and I still need frequent loop measurements to get to the crossed over state. Having ITMY misaligned and using the digital AS55Q spectrum as an out of loop monitor has been very helpful. 

To get around the problems between the pomona LPF and low CM board input impedance, I've placed the LPF at the CM board fast output. This won't work as a permanent solution, since we only want to lowpass the ALS signal, but it should be fine for a single arm test. 

However, I kept getting blown out of lock when turning up the AO gain, but well before I really expect any real action from the fast path. Looking at the OLTF, I was seeing some large spike at ~36kHz nearing 0dB loop gain with unstable phase. This prompted me to look at the ALS error signal out to higher bandwidth with the SR785; before I only ever looked at it through the digital system. 

So, with the X arm locked via POX11 I, and ITMY misaligned to use AS55 as an out of loop sensor, I measured the spectrum of the I ouput of the ALS X demod board (which was set to be near a zero crossing via the delay line), and the Q Mon of the AS55 demod board. 

Both ALS and AS55 show a sharp line at around 36.5kHz, so something is really happening in the IFO at this frequency. Koji might have seen an indication of this back in March.

What's going on here? And what would be different about PRFPMI that wouldn't have made this a problem for locking?

 I looked at REFL11 and REFL55 during PRMI lock - the line is there.

In fact, it is even visible in REFL11 I from a single bounce off of the PRM (ITMs misaligned).

This led me to look at the IMC error point (via the OUT2 on the servo board, no compensation for the input gain). Also there!

One the Wiki (https://wiki-40m.ligo.caltech.edu/40mHomePage), we have a Mech Resonance page for mechanical frequencies and a PEM page where we want to list the sources of all of our environmental lines. So please put in an entry when you find out what's at this frequency. This reminds me that I need to upload my MC2 COMSOL eigenmode analysis.

Fast ALS control continues to elude me. 

I fixed my LPF to take the input impedance of the CM board input into account; this unfortunately results in about -12dB DC gain of the ALS signal due to voltage-divider-y things, but by my estimation, this still puts the DFD noise above the input-referred voltage noise of the input AD829 on the CM board, so it'll do for now. The 120Hz pole shows up as expected when comparing the usual digital channels and the CM_SLOW output, and is digitally compensated with a zero at 120Hz (with a digital pole at 5k so nothing blows up). 

However, there seems to be some zero in the analog path somewhere that spoils the loop shape for the AO path. Here's a measurement of the X arm OLG from 10-100kHz, when the digital control is happening with ~100Hz UGF via ALS X I -> CM IN2 -> CM_SLOW -> LSC_CARM -> ETMX, and there is some AO action via ALS X I -> CM IN2 -> IMC IN2

The peak is recognizable as the gain peaking in the IMC servo (and changes predictably with changes to the IMC crossover and loop gains), which is expected. However, one can see that the magnitude is roughly flat before the peak, and the phase is around 0. With the 1/f LPF, we should see some downward slope and phase starting around -90. 

Thus, there must be some zero in the fast or common path, maybe at a few kHz where the digital loop wouldn't really see its effect. I'm not sure what it could be at this point in time.

One thought I had is that I never really checked the TF of DFD response to frequency modulation of the RF beat. I used an SR785 to drive the external FM input of a Fluke 1061A synthesizer, and saw it to be totally flat from 1-100kHz with carriers from 30-100MHz, so that should be fine. (For a little while I was confused by what seemed to be some heavy high-passing going on, but it turns out that the Fluke just can't push much low frequency FM; the manual says -3dB at 20Hz.)

INCORRECT INFO IN THIS ELOG HAS BEEN REMOVED. SEE THIS ELOG FOR THE UPDATED INFO.

Summary:

With the help of a tester board, I verified the mapping between fast BIO DB37 pins, and pins on the IDC50 connectors that are to be broken out to the whitening boards. I will enlist Chub to implement this mapping in hardware later today.

Details:

1. The LSC PD demodulated signals are optionally whitened before acquisition by our RTCDS ADCs.
2. The switching of each channel's whitening (enable/disable) is done by a single bit from the fast (a.k.a. RTCDS) system's BIO cards.
3. The whitening boards live inside Eurocrates.
4. The aforementioned switching signal needs to be sent to the whitening boards via the backplane of the Eurocrate.
5. This requires some cross-connect based cable splicing between the BIO card outputs and the P2 connectors of the whitening boards in the Eurocrates.
6. This connection was accidentally destroyed during the war on cross-connects at 1Y2. I couldn't find a wiring diagram anywhere.
7. Today, with the help of a tester board, I verified the mapping by toggling the appropriate channels on the MEDM screen, and verifying the correct LEDs on the tester board were toggled.
8. Map will be posted here after the meeting... Also now on the wiki.

Update 2019 Sep 19 1730: The pin numbers of the IDC 50 connector are all off by 1. i.e. 3-->4 and so on. I will fix this shortly. The problem was because of me looking at the pinout for the wrong gender of IDC50 connectors.

[KA, GV]

Summary:

1. New cross connect system for splicing the fast BIO signals for whitening switching to the P2 connectors was installed and tested at 1Y2.
2. It passed a first round of tests. 😁 
3. As of now, I believe all the necessary electrical connections have been made at 1Y2/1Y3, and we are ready for testing the c1iscaux system.

Details:

1. We did some testing in the office area, and found several wiring mistakes. These were all rectified. Attachment #1 is an accurate reflection of the implemented wiring scheme (softcopy in the 40m google sheets area). Be aware that the IDC 50 pin connector pin-out is tricky, and you have to be aware of the difference between male/female connector when looking for this pin-out on the internet.
2. In order to facilitate further testing, we re-routed the ADC0 SCSI cable that was unplugged on the overhead cable tray, and plugged it back into the c1lsc expansion chassis. This action necessitated a reboot of the vertex FEs, but everything came back alright.
3. Did some general neatenign and strain relieving. Removed a few existing cross-connects to make space for our new terminal blocks.
4. Attachment #2 shows the layout of the terminal blocks. Note the unusual (vertical) order of the orange terminal blocks.
5. The final integrated CDS test done was the following:
   • Set whitening gain for channel under test to 45dB, so that the dark noise level is boosted to a measurable level such that a change can be seen with the whitening enabled/disabled.
   • Compare the ASD of the signal between 30-100 Hz with the whitening engaged/disengaged.
   • Example result shown in Attachment #3.I believe the whitening is 15:150 (z:p) 

Tomorrow:

1. Recover POX/POY locking,.
2. ...

[Paco, Anchal-remote-support, Yuta]

We added fast channels to BHD DC PDs.
C1:LSC-DCPD_(A|B)_IN1 are now available, but C1:HPC-DCPD_(A|B)_IN1 still gives us zero.

c1hpc situation -> not good
 - We can see the slow signal at C1:X07-MADC1_EPICS_CH16 (DC PD A) and CH17 (DC PD B)
 - C1:HPC-DCPD_(A|B)_IN1 is there, but zero.
 - We have modified c1hpc model to add DCPD_(A|B) filters in front of the input matrix (see Attachment #1).
 - After modifying the model, we run
ssh c1sus2
rtcds make c1hpc
rtcds install c1hpc
ssh fb1
sudo systemctl restart daqd_*

 - After this, we got 0x2000 error. So, we ran the following. This removed 0x2000 error, but DCPD signals are still zero. They are also not available in C1HPC-MONITOR_ADC1.adl screen (see Attachment #3).
ssh c1sus2
rtcds restart c1hpc

c1lsc situation -> good
 - We could see the slow signal at C1:X04-MADC1_EPICS_CH4 (DC PD A) and CH5 (DC PD B), and also C1:LSC-DCPD_(A|B)_NORM after making C1:LSC-DCPD_(A|B)_POW_NORM=1. The ADC channel and DCPD channel are exactly the same.
 - After confirming the above, we modified the c1lsc model to add DCPD_(A|B) filters in front of the input matrix (see Attachment #2).
 - After modifying the model, we run
ssh c1lsc
rtcds make c1lsc
rtcds install c1lsc
ssh fb1
sudo systemctl restart daqd_*

 - After this, we also got 0x2000 error. We also noticed that, for example, C1:X04-MADC0_EPICS_CH31 and C1:LSC-ASDC_INMON are different, which used to be the same (ASDC_INMON was largely attenuated).
 - In the end, we run the following to remove 0x2000 error, but it crashed c1lsc, as well as c1sus, c1ioo.
ssh c1lsc
rtcds restart c1lsc

 - So, we did rebootC1LSC.sh. This made c1lsc, c1ioo and c1sus as green as before, except for RFM issue in TRX/TRY, like we saw in June. We followed the steps in 40m/16887 to hard reboot c1iscex/c1iscey and ran rebootC1LSC.sh again. This made C1CDS_FE_STATUS.adl screen as green as before (see Attachment #3).

 - Fast channels C1:LSC-DCPD_(A|B)_IN1 are now available. They are also available in C1LSC-MONITOR_ADC1.adl screen (see Attachment #3).

Rana and I now seem to have the fast front end computers (c1lsc, c1sus, c1ioo, c1iscex and c1iscey) up and running!  Hooray!

It seemed that we needed to change the soft links back to hard links for rtcds and rtapps on the front end machines.  On c1ioo, we did:

cd /opt

sudo rm -rf rtcds

sudo rm -rf rtapps

sudo mkdir rtcds

sudo mkdir rtapps

sudo chown controls:1001 rtcds

sudo chown controls:1001 rtapps

mount /opt/rtcds

mount /opt/rtapps

At this time, the front end fstab had several other options in addition to "nolock" for both rtcds and rtapps.  They had rw,bg,user,nolock.  This state still had some permissions problems.  (Later, we have decided that perhaps our next step was unneccesary, since it still left us with (fewer) permissions problems. Taking out the rw,bg,user options from the front end fstab seems to have fixed all permissions issues, so maybe this next chmod step didn't need to be done.  But it was done, so I record it for completeness).

On chiara, we did:

cd /home/cds/rtcds

sudo chmod -R 777 *

Then on c1iscex, I didn't have to deal with the soft links, but I did need to mount the rtcds and rtapps directories so that I could see files in them.  I just did the last 2 operations from the c1ioo list above (mount /opt/rtcds and mount /opt/rtapps). 

Since we were still seeing some (fewer) permissions problems, we took out the extra options in the front ends' fstab that Rana had added.  Rebooting c1iscex after this, everything came back as expected.  Nice!

I think that, at this point, remotely rebooting (sudo shutdown -r now) the other front ends made everything come back nicely. Since we had gotten the fstab situation correct, we didn't have to by-hand mount any directories, and all of the models restarted on their own.  Finally!

For posterity, here are things that we'll want to remember:

Frame builder's fstab, in /etc/fstab (only the uncommented lines, since there are lots of comments):

/dev/sdb1               /               ext3            noatime         0 1
/swapfile               none            swap            sw              0 0
shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0
/dev/sda1               /frames         ext3    noatime         0 0
192.168.113.104:/home/cds/                      /cvs/cds        nfs     _netdev,auto,rw,bg,soft      0 0
192.168.113.104:/home/cds/rtcds                  /opt/rtcds     nfs     _netdev,auto,rw,bg,soft 0 0
192.168.113.104:/home/cds/rtapps                 /opt/rtapps    nfs     _netdev,auto,rw,bg,soft 0 0


Fast front end fstabs, which are on the framebuilder in /diskless/root/etc/fstab:

master:/diskless/root                   /               nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/usr                             /usr            nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                            /home           nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                                    /proc           proc    defaults          0 0
none                                    /var/log        tmpfs   size=100m,rw    0 0
none                                    /var/lib/init.d tmpfs   size=100m,rw    0 0
none                                    /dev/pts        devpts  rw,nosuid,noexec,relatime,gid=5,mode=620        0 0
none                                    /sys            sysfs   defaults        0 0
master:/opt                             /opt            nfs     async,hard,intr,rw,nolock  0 0
192.168.113.104:/home/cds/rtcds         /opt/rtcds      nfs     nolock                     0 0
192.168.113.104:/home/cds/rtapps        /opt/rtapps     nfs     nolock                     0 0

We ran again this method but with the 'b' parameter as a matrix instead. This provides more gain on some off-diagonal terms than others. This gave us a better convergence with the code reaching to the tolerance level provided (0.01 distance of S matrix from identity) within 16 iterations (~17 mins).

Attachment 1 again shows how the off-diagonal terms go down and how the overall distance of sensing matrix from identity goes down. This is 'Cross coupling budget' of the coils as iterations move forward.

Jumping to near zero-crossing:

• Rana mentioned a ezlockin code which first makes 5 step changes in output matrix without using feedback and calculates the changes required to reach zero-crossing in the behavior of the off-diagonal terms during these steps.
• This is similar to what we did above by hand where we increased the value of b for slowly converging off-diagonal elements.
• We plan to implement this 'jump' to near zero-crossing method next. Aim is to get a coil balancing code that does the job in ~5 min.
• We have been throwing away imaginary part of sensing matrix so far. We wanted to get to some owrking solution before we try more complex stuff. We have to figure out global phases in each transfer function estimate to rotate the measured transfer function appropriately.

convergence is great.

Next we wanna get the F2A filters made since most of the IMC control happens at f < 3 Hz. Once you have the SUS state space model, you should be able to see how this can be done using only the free'swinging eigenfrequencies. Then you should get the closed loop model including the F2A filters and the damping filters to see what the closed loop behavior is like.

I think I mis-spoke about the balancing channels before. The ~20 Hz balancing could go into either the COIL banks or the SUS output matrix.

I believe its more conceptually clean to do this as gains in the outputmatrix, and leave the coil gains as +/- 1. i.e. we would only use the coil gains to compensate for coil/magnet actuation strength.

Then the high frequency balance goes into the outputmatrix. The F2A and A2L decoupling filters would then be generated having a high frequency gain = 1.

So I made coffee at 1547 and was astonished to find the above. Its a sad, very sad day.

At first I thought that something (a gravity wave?) or someone, accidentally hit the thing and it fell and broke. But Koji told me that the janitor was cleaning around the thing and it did indeed fell accidentally.

I turned off fb40m2 and fb40m temporarily while we added an extra power strip  to the (new) 1X6 rack at the bottom in the back.  This is to allow for the addition of the 4600 computer  given to us by Rolf (which needs a good name) into the rack above the fb machine.  The fb40m2 was unfortunately plugged into the main power connectors, so we unplugged two of its cables, and put them into the new strip. While trying to undo some of the rats nest of cables in the back I also powered down and unpluged briefly the c0dcu1, the pem crate, and the myrinet bypass box.

I am in the process of bringing those machines back up and restoring the network.

Also this morning, Megatron was moved from the end station into the (new) 1X3 rack, along with its router.  This is to allow for the installation of the new end computer and IO chassis.

 We would appreciate some plots. Learning curves of recurrent NN working as a plant are interesting. For harmonic oscillator your RNN should not contain any hidden layers - only 1 input and 1 output node and 2 delays at each of them. Activation function should be linear. If your code is correct, this configuration will match oscillator perfectly. The question is how much time does it take to adapt.

Does FANN support regularization? I think this will make your controller more stable. Try to use more advanced algorithms then gradient descent for adaptation. They will increase convergence speed. For example, look at fminunc function at Matlab.

Hi everyone,

I've been on break this week, so in addition to working at my lab here, I've done some NN stuff. In response to Den's response to my last post, I've included learning curve plotting capabilities, 

I've explored all of the currently documented capabilities of FANN (Fast Artificial Neural Network - it's a C library) (most likely, there are additions to the library floating around in open-source communities, but I have yet to look into those). There is extensive FANN documentation on the FANN website (http://leenissen.dk/fann/html/files/fann-h.html), but I'll cut it down to the basics here:

FANN Neural Network Architectures

standard: This creates a fully connected network, useful for small networks, as in the reference plant case 

sparse: This creates a sparsely connected network (not all of the connections between all neurons exist at all times), useful for large networks, but not useful in the reference plant case, since the number of neurons is relatively small

shortcut: This creates some connections in the network which skip over various hidden layers. Not useful in the harmonic oscillator case since there are no hidden layers. Probably won't be useful in a better-modeled referrence plant since this reduces the non-linear capabilities of the model.

FANN Training  

TRAIN_INCREMENTAL: updates the weights after every iteration, rather than after each epoch. This is faster than the other algorithms for the reference plant.

TRAIN_BATCH: updates the weights after training on the whole set. This should not be used on batches of data for the reference plant, seeing as the time history dependence of the plant is smaller than the size of the entire data set. 

TRAIN_RPROP: batch training algorithm which updates the learning parameter.

TRAIN_QUICKPROP: updates the learning parameter, and uses second derivative information, instead of just first derivative, for backpropagation. 

FANN Activation Functions

FANN offers a bunch of activation functions, including a function FANN_ELLIOT, which is essentially the "signmoid like" activation function Den and I used this summer, which runs in the order of multiplication and addition. The function parameters (steepness) can also be set.

FANN Parameters

As usual, the learning parameter can be set. While over the summer we worked with lower learning parameters, in the case of the harmonic oscillator reference plant, since the error is low after the first iteration, higher learning parameters (0.9, for example), work better. However, this is a very isolated case, and, in general, lower parameters, though convergence is slower, produce more optimal results. 

The learning momentum is another parameter that can be set - the momentum factor is a coefficient in the weight adjustment equation which allows for the difference in weights beyond the previous weight to be factored in. In the case of the reference plant, a higher learning momentum (0.9) is optimal, although in most cases, a lower learning momentum is optimal so that the learning curve doesn't oscillate terribly. 

FANN does not explicitly include regularization, but this can be implemented by checking the MSE  at each iteration against the MSE at the n previous iterations, where n is the regularization parameter, and stopping training if there is no significant decrease (also determined by a parameter). The error bound I specified during training was 0.0001

The best result for the reference plant was obtained using FANN_TRAIN_INCREMENTAL, a "standard" architecture, a learning rate of 0.9 (as explained above) and a learning momentum of 0.9 (these values should NOT be used for highly non-linear and more complicated systems). 

I have included plots of the learning curves - each title includes the architecture, the learning algorithm, the learning parameter, and the learning momentum if I modified it explicitly.

All of my code (and more plots!) can be found in /users/masha/neural_plant

On the whole, FANN has rather limited capabilities, especially in terms of learning algorithms, where it only has 4 (+ all of the changes one can make to parameters and rates). It is, however, much more intuitive to code with and faster han the Matlab NN library, although the later has more algorithms. I'll browse around for more open-source packages. 

Best,

Masha

[Kiwamu, Katrin]

Red and blue curves: frequency fluctuation of the beat node between PSL and YARM laser.

Green and broen curves: Actuation on ETMY.  In ALS_CONTROL.adl  ETMY filter bank 4 and 5 were switched on. Gain was 0.3

Nice reduction of the frequency fluctuation.

Y axis is in volts^2 per counts. In order to go to MHz/sqrt(Hz) you have to take the square root and then times [20Volts/(2^16)counts]*[10Hz/0.04V].

Started to scan the cavity, but this didn't work. Green light all out of lock. IR beam was badly aligned to cavity. Now, my time is over and I have to leave you.

Thanks, for your help and the nice time.

Below is an inventory of the signal feedthroughs that need to be installed on the vacuum Acromag crate this week.

**The original documentation lists five satellite boxes (one for each test mass chamber and one for the beamsplitter chamber), but Chub reports not all of them are in use. We may remove the ones not used.

- New feedthrus [4xDB25 Qty 4 / 8xDB25 Qty 1] are placed on the wire shelf at the entrance -> Jordan, please clean them.

- There are plenty of 2" DLC mounts. There are also many 1.5" mounts but they are less useful.
  We need at least 3 1" moounts and 1 1" or 2" lens mount (and the lens). Let's purchase them on Thorlabs. I'll work on the order.

[Koji, Annalisa, Manasa]

NPRO with controller from ATF joins the 40m. We have put it on the POY table where we plan to use it for ABSL.

I've added 4 proposed schemes for implementing ALS in voyager. Major thing to figure out is what AUX laser would be and how we would compare the different PSL and AUX lasers to create an error signal for ALS. Everywhere below, 2um would mean wavelengths near 2 um including the proposed 2128nm. Since it is not fixed, I'm using a categorical name. Same is the case for 1um which actually would mean half of whatever 2 um carries.

Higher Harmonic Generation:

• We can follow the current system of ALS with using 1.5 times PSL frequency as AUX instead of second harmonic as 1 um is strongly absorbed in Si.
• To generate 1.5 times PSL frequency, three stages would be required.
  • SHG: Second Harmonic Generation mode matched to convert 2um to 1um. If we are instead making 2 um from 1um to start with, this stage will not be required.
  • SFG: Sum Frequency Generation mode matched to sum 2um photon and 1um photon to give 0.65 um photon.
  • DPDC: Degenerate Parametric Down Conversion mode matched to convert 0.65 um to 1.3 um (which would be 1.5 times PSL frequency).
• To compare, we can either convert pick-off from PSL to AUX frequency by doing the above 3 stages (Scheme II).
• Or we can just do SHG and SFG at PSL pick-off and do another SHG at AUX end (Scheme I) to compare the AUX and PSL both converted to 0.65 um (which would be 2 times AUX and 3 times PSL frequency).
• This method would have added noise from SHG, SFG and DPDC processes along with issues to be inefficiency of conversion.

Arbitrary AUX frequency:

• We can get away with using some standard laser near 1.5 um region directly as AUX. Most probably this would be 1550 nm.
• What's left is to devise a method of comparing 1.5 um and 2um frequencies. Following are two possible ways I could think of:

Using a frequency comb:

• Good stable frequency combs covering the wavelength region from 1.5 um to 2 um are available of the shelf.
• We would beat PSL and transmitted AUX separately with the frequency comb. The two beat note frequencies would be:
  
  
• Here, m1 and m2 represent the nearest modes (comb teeth) of frequency comb to PSL and AUX respectively.
• Carrier Envelope Offset frequency () can be easily generated by using an SHG crystal in front of the Frequency comb. This step is not really required since most of the modern frequency combs now comb with inbuilt zero stabilization.
• Mixing above beatnotes with would remove from them along with any noise associated with .
• Further, a Direct Digital Synthesis IC is required to multiply the AUX side RF signal by m1/m2. This finally makes the two RF signals to be:
  
  
• Which on mixing would give desired error signal for DFD as :
  
• This method is described in Stenger et al. PRL. 88, 073601 and is useful in comparing two different optical frequencies with a frequency comb with effective cancellation of all noise due to the frequency comb itself. Only extra noise is from the DDS IC which is minimal.
• This method, however, might be an overkill and expensive. But in case (for whatever reason) we want to send in another AUX at another frequency down the 40m cavity, this method allows the same setup to be used for multiple AUX frequencies at once.

Using a Transfer Cavity:

• We can make another more easily controlled and higher finesse cavity with a PZT actuator on one of the mirrors.
• In the schematic, I have imagined it has a triangular cavity with a back end mirror driven by PZT.
• Shining PSL from one side of the transfer cavity and employing the usual PDH, we can lock the cavity to PSL.
• This lock would require to be strong and wide bandwidth. If PZT can't provide enough bandwidth, we can also put an EOM inside the cavity! (See this poster from Simon group at UChicago)
• Another laser at AUX frequency, called AUX2 would be sent from the other side of the cavity and usual PDH is employed to lock AUX2 to the transfer cavity.
• So clearly, this cavity also requires coatings and coarse length such that it is resonant with both PSL and AUX frequencies simultaneously.
• And, the FSS for AUX2 needs to be good and high bandwidth as well.
• The transmitted AUX2 from the transfer cavity now would carry stability of PSL at the frequency of AUX and can be directly beaten with transmitted AUX from the 40m cavity to generate an error signal for DFD.
• I believe this is a more doable and cheaper option. Even if we want to do a frequency comb scheme, this could be a precursor to it.

_________________________

EditTue Jul 21 17:24:09 2020: (Jamie's suggestion)

Using Mode Cleaner cavity as Transfer Cavity:

• If we coat the mode cleaner cavity mirrors appropriately, we can use it to lock AUX2 laser (mentioned above).
• This will get rid of all extra optics. The only requirement is for FSS to be good on AUX2 to transfer PSL (MC) stability to AUX frequency.
• I've added suggested schematic for this scheme at the bottom.

After discussing with Koji, I decided to try and align the input beam polarization at the PSL fiber coupler to one of the special axes of the PM fiber. The motivation is to try and narrow down the source of the large RF beatnote amplitude drift I noticed and reported last night.

The setup for doing so is shown in Attachment #1 - essentially, I setup one of the newly purchased couplers in a mount, set up a PBS, and placed two photodiodes at the S and P ports of the PBS. The idea is to rotate the input coupler in its mount, thereby maximizing the PER (monitored on two Thorlabs PDA520s - I didn't check the gain balance of them). 

I spent ~30mins doing some preliminary trials just now, and, I was able to achieve a PER of ~1/20. But I think much better numbers were reported in this SURF project (although I'm not entirely sure I understand that measurement). I will spend a little more time tweaking the alignment. The procedure is tricky as at some point, simply rotating the mount reduces the mode-matching efficiency into the fiber so much that it is not possible to get a meaningful PER measurement from the photodiodes. I'm adjouring for now, more to follow...

Summary:

Current configuration of PSL free-space to fiber coupling is:

• 3.25 mW / 4.55mW (~71%) coupling efficiency, both numbers measured with Ophir power meter, Filter OFF
•  (I choose to define it in this way as opposed to the reciprocal) of 75 (~19dB). The uncertainty in this number is large (see discussion), but I am confident that we have >10dB, which while isn't as good as can be, is sufficient for the main motivation behind this work.

Motivation:

I had noticed that the RF beat amplitude was fluctuating by up to 20dBm as viewed on the control room analyzer. As detailed in my earlier elog, I suspected this to be because of random polarization drift between the PSL and EX fields incident on the Fiber coupled PDs. Since I am confident the problem is optical (as opposed to something funny in the electronics), we'd like to be able to isolate which of the many fiber segments is dominating the contribution to this random polarization drift.

Some useful references:

1. General writeup about how PM fibers work and PER. Gives maximum achievable PERs for a given misalignment of incident beam relative to one of the two birefringent axes.
2. Another similar writeup. This one put me onto the usefulness of the alignment keys on the fibers.
3. Thorlabs PM980 specs - this tells us about the orientation of the two axes for the kind of fibers we use.

Procedure and details:

• The principle of operation behind polarization maintaining (PM) fibers is that intentional birefringence is introduced along two perpendicular axes in the fiber.
• As a result of which light propagates with different phase velocity along these axes.
• For an arbitrary incident field with E-field components along both axes, it is almost impossible to predict the output polarization as we do not know the length of propagation along each axis to sufficient precision (it is also uncontrolled w.r.t. environmental fluctuations). So even if you launch linear polarization into the fiber, it is most likely that the output polarization state will be elliptical.
• But if we align the incident, linear polarization along one of the two axes, then we can accurately predict the polarizaiton at the output, to the extent that the fiber doesn't couple power in the two axes during propagation. I cant find a spec for the isolation between axes for the fiber we use, but the specs I could find for other fiber manufacturers suggest that this number is >30dB, so I think the assumption is a fair one.
• A useful piece of information is that the alignment key on the fibers gives us information about the orientation of the birefringent axes inside the fiber. For the Thorlabs fibers, it seems that the alignment key lines up with the stress-inducing rods inside the fiber (i.e. the slow axis). I confirmed this by looking at the fiber with the fiber scope.
• The PSL pickoff beam I am using for this setup is from the transmission of the PBS after the Faraday. So this field should have relatively pure P-polarization.
• The way I have set up the fiber on the PSL table, the fast axis of the fiber corresponds to P-polarization (i.e. E field oscillates parallel to the plane of the optical table). Actually, it was this alignment that I tweaked in this work.
• Using the information about the alignment key defining polarization axes on the fiber, I also set up the output fiber coupler such that the fast axis lined up as near parallel to the plane of the optical table as possible. In this way, the beam incident on the PBS at the output of my setup should be pure P-polarizaiton if I setup my input alignment into the fiber well.
• I tweaked the rotation of the Fiber mount at the input coupler to maximize the ratio of P_p / P_s, as measured by the pair of PDs at the output. 
• As #1 of my listed references details, you need to align the incident linear polarization to one of the two birefringent axes to closer than 6 degrees to achieve a PER of >20dB. While this sounds like a pretty relaxed requirement, in practise, it is about as good as we can hope to achieve with the mounts we have, as there is no feature that allows us to lock the rotational degree of freedom once we have optimized the alignment. Any kind of makeshift arrangement like taping the rotating part to the mount is also flaky, as during the taping, we may ruin the alignment.
• Attachment #1 shows the result of my alignment optimization - the ratio P_p / P_s is about 75.
• The uncertainty on the above number is large. Possible sources of error:
  • Output coupler is not really aligned such that fast axis corresponds to P-polarizaiton for the output PBS.
  • The two photodiodes' gain balance was not checked.
  • The polarization content of the input beam was not checked.
  • The PBS at the output could be slightly misaligned relative to the S/P polarization directions defined by the tabletop.
  • The PBS extinction ratio was not checked.
• But anyways, this is a definite improvement on the situation before. And despite the large uncertainty, I am confident that P_p / P_s is better than 10dB.
• Moreover, Steve and I installed protective tubing on the lengths of fiber that were unprotected on the PSL table, this should help in reducing stress induced polarization drifts in the fiber, at least in these sections of fiber.
• So I think the next step is to monitor the stability of the RF beatnote amplitude after these improvements. At some point, we need to repeat this procedure for the EX and EY fibers as well.
• If the large drifts are still seen, the only thing we can exclude as a result of this work is the section of fiber from the PSL light coupler to the beat mouth.

Last week, we were talking about reviving the Fiber ALS box. Right now, it's not in great shape. Some changes to be made:

1. Supply power to the PDs (Menlo FPD310) via a power regulator board. The datasheet says the current consumption per PD is 250 mA. So we need 500mA. We have the D1000217 power regulator board available in the lab. It uses the LM2941 and LM2991 power regulator ICs, both of which are rated for 1A output current, so this seems suitable for our purposes. Thoughts?
2. Install power decoupling capacitors on the PDs.
3. Clean up the fiber arrangement inside the box.
4. Install better switches, plus LED indicators.
5. Cover the box.
6. Install it in a better way on the PSL table. Thoughts? e.g. can we mount the unit in some electronics rack and route the fibers to the rack? Perhaps the PSL IR and one of the arm fibers are long enough, but the other arm might be tricky.

Previous elog thread about work done on this box: elog11650

Today, I borrowed the fiber microscope from Johannes and took a look at the fibers coupled to the PDs. The PD labelled "BEAT PD AUX Y" has an end that seems scratched (Attachments #1 and #2). The scratch seems to be on (or at least very close to) the core. The other PD (Attachments #3 and #4) doesn't look very clean either, but at least the area near the core seems undamaged. The two attachments for each PD corresponds to the two available lighting settings on the fiber microscope.

I have not attempted to clean them yet, though I have also borrowed the cleaning supplies to facilitate this from Johannes. I also plan to inspect the ends of all other fiber connections before re-installing them.

Today, with Johannes' help, I cleaned the fiber tips of the photodiodes. The effect of the cleaning was dramatic - see Attachments #1-4, which are X Beat PD, axial illumination, X Beat PD, oblique illumination, Y beat PD, axial illumination, Y beat PD, oblique illumination. They look much cleaner now, and the feature that looked like a scratch has vanished.

The cleaning procedure followed was:

• Blow clean air over the fiber tip
• First, we tried cleaning with the Q-tip like tool, but the results weren't great. The way to use it is to dip the tip in the cleaning solvent for a few seconds, hold the tip to the fiber taking into account the angled cut, and apply 10 gentle quarter turns.
• Next, we tried cleaning with the wipes. We peeled out an approximately 5" section of the wipe, and laid it out on the table. We then applied cleaning solvent liberally on the central area where we were sure we hadn't touched the wipe. Then you just drag the fiber tip along the soaked part of the wipe. If you get the angle exactly right, the fiber glides smoothly along the surface, but if you are a little misaligned, you get a scratchy sensation. 
• Blow dry and inspect.

I will repeat this procedure for all fiber connections once I start putting the box back together - I'm almost done with the new box, just waiting on some hardware to arrive.

I completed the revamp of the box, and re-installed the box on the PSL table today. I think it would be ideal to install this on one of the electronic racks, perhaps 1X2 would be best. We would have to re-route the fibers from the PSL table to 1X2, but I think they have sufficient length, and this way, the whole arrangement is much cleaner.

Did a quick check to make sure I could see beat notes for both arms. I will now attempt to measure the ALS noise with this revamped box, to see if the improved power supply and grounding arrangement, as well as fiber cleaning, has had any effect.

Photos + power budget + plan of action for using this box to characterize the green PDH locking to follow. 

For quick reference: here is the AM/PM measurement done when we re-installed the repaired Innolight NPRO on the new X endtable.

Attachment #1 is the updated diagram of the Fiber ALS setup. I've indicated part numbers, power levels (optical and electrical). For the light power levels, numbers in green are for the AUX lasers, numbers in red are for the PSL.

I confirmed that the output of the power splitter is going to the "RF input" and the output of the delay line is going to the "LO input" of the demodulator box. Shouldn't this be the other way around? Unless the labels are misleading and the actual signal routing inside the 1U chassis is correctly done :/

• Mode-matching into the fibers is rather abysmal everywhere.
• In this diagram, only the power levels measured at the lasers and inputs of the fiber couplers are from today's measurements. I just reproduced numbers for inside the beat mouth from elog13254.
• Inside the beat mouth, the PD output actually goes through a 20dB coupler which is included in this diagram for brevity. Both the direct and coupled outputs are available at the front panel of the beat mouth. The latter is meant for diagnostic purposes. The number of -8dBm of beat @30MHz is quoted using the direct output, and not the coupled output.

Still facing some CDS troubles, will start ALS recovery once I address them.

Attachment #2 is the svg file of Attachment #1, which we can update as we improve things. I'll put it on the DCC 40m tree eventually.

I did a cursory check of the ALS signal chain in preparation for commissioning the IR ALS system. The main elements of this system are shown in my diagram in the previous elog in this thread.

Questions I have:

1. Does anyone know what exactly is inside the "Delay Line" box? I can't find a diagram anywhere.
   • Jessica's SURF report would suggest that there are just 2 50m cables in there.
   • There are two power splitters taped to the top of this box.
   • It is unclear to me if there are any active components in the box.
   • It is unclear to me if there is any thermal/acoustic insulation in there.
   • For completeness, I'd like to temporarily pull the box out of the LSC rack, open it up, take photos, and make a diagram unless there are any objections.
2. If you believe the front panel labeling, then currently, the "LO" input of the mixer is being driven by the part of the ALS beat signal that goes through the delay line. The direct (i.e. non delayed) output of the power splitter goes to the "RF" input of the mixer. The mixer used, according to the DCC diagram, is a PE4140. Datasheet suggests the LO power can range from -7dBm to +20dBm. For a -8dBm beat from the IR beat PDs, with +24dB gain from the ZHL3A but -3dB from the power splitter, and assuming 9dB loss in the cable (I don't know what the actual loss is, but according to a Frank Seifert elog, the optimal loss is 8.7dB and I assume our delay line is close to optimal), this means that we have ~4dBm at the "LO" input of the demod board. The schematic says the nominal level the circuit expects is 10dBm. If we use the non-delayed output of the power splitter, we would have, for a -8dBm beat, (-8+24-3)dBm ~13dBm, plus probably some cabling loss along the way which would be closer to 10dBm. So should we use the non-delayed version for the LO signal? Is there any reason why the current wiring is done in this way?

After labeling cables I would disconnect, I pulled the box out of the LSC rack. Attachment #1 is a picture of the insides of the box - looks like it is indeed just two lengths of cabling. There was also some foam haphazardly stuck around inside - presumably an attempt at insulation/isolation.

Since I have the box out, I plan to measure the delay in each path, and also the signal attenuation. I'll also try and neaten the foam padding arrangement - Steve was showing me some foam we have, I'll use that. If anyone has comments on other changes that should be made / additional tests that should be done, please let me know.

20180111_2200: I'm running some TF measurements on the delay line box with the Agilent in the control room area (script running in tmux sesh on pianosa). Results will be uploaded later.

With Johannes' help, I re-installed the box in the LSC electronics rack. In the end, I couldn't find a good solution to thermally insulate the inside of the box with foam - the 2U box is already pretty crowded with ~100m of cabling inside of it. So I just removed all the haphazardly placed foam and closed the box up for now. We can evaluate if thermal stability of the delay line is limiting us anywhere we care about and then think about what to do in this respect. This box is actually rather heavy with ~100m of cabling inside, and is right now mounted just by using the ears on the front - probably should try and implement a more robust mounting solution for the box with some rails for it to sit on.

I then restored all the cabling - but now, the delayed part of the split RF beat signal goes to the "RF in" input of the demod board, and the non-delayed part goes to the back-panel "LO" input. I also re-did the cabling at the PSL table, to connect the two ZHL3-A amplifier inputs to the IR beat PDs in the BeatMouth instead of the green BBPDs.

I didn't measure any power levels today, my plan was to try and get a quick ALS error signal spectrum - but looks like there is too much beat signal power available at the moment, the ADC inputs for both arm beat signals are overflowing often. The flat gain on the AS165 (=ALS X) and POP55 (=ALS Y) channels have been set to 0dB, but still the input signals seem way too large. The signals on the control room spectrum analyzer come from the "RF mon" ports on the demod board, and are marked as -23dBm. I looked at these peak heights with the end green beams locked to the arm cavities, as per the proposed new ALS scheme. Not sure how much cable loss we have from the LSC rack to the network analyzer, but assuming 3dB (which is the Google value for 100ft of RG58), and reading off the peak heights from the control room analyzer, I figure that we have ~0dBm of RF signal in the X arm. => I would expect ~3dBm of signal to the LO input. Both these numbers seem well within range of what the demod board is designed to handle so I'm not sure why we are saturating.

Note that the nominal (differential) I and Q demodulated outputs from the demod board come out of a backplane connector - but we seem to be using the front panel (single-ended) "MON" channels to acquire these signals. I also need to update my Fiber ALS diagram to indicate the power loss in cabling from the PSL table to the LSC electronics rack, expect it to be a couple of dB.

Summary:

I am facing two problems:

1. The X arm beat seems to be broadband noisier than the Y arm beat - see Attachment #1. The Y-axis calibration is uncertain, but at least the Y beat has the same profile as the reference traces, which are for the green beat from a time when we had ALS running. There is also a rather huge ~5kHz peak, which I confirmed isn't present in the PDH error/control signal spectra (with SR785).
2. The Y-arm beat amplitude, at times, "breathes" in amplitude (as judged by control room analyzer). Attachment #2 is a time-lapse of this behaviour (left beat is X arm beat, right peak is the Y arm peak) - I caught only part of it, the the beat note basically vanishes into the control room noise floor and then comes back up to almost the same level as the X beat. The scale is 10dB/div. During this time, the green (and IR for that matter) stay stably locked to the arm - you'll have to take my word for it as I have no way to sync my video with StripTool Traces, but I was watching the DC transmission levels the whole time. The whole process happens over a few (1< <5) minutes - I didn't time it exactly. I can't really say this behaviour is periodic either - after the level comes back up, it sometimes stays at a given level almost indefinitely.

More details:

• Spent some time today trying to figure out losses in various parts of the signal chain, to make sure I wasn't in danger of saturating RF amplifiers. Cabling from PSL table -> LSC rack results in ~2dB loss.
• I will upload the updated schematic of the Beat-Mouth based ALS - I didn't get a chance to re-measure the optical powers into the Beat Mouth, as someone had left the Fiber Power Meter unplugged, and it had lost all of its charge .
• The Demod boards have a nice "RF/LO power monitor" available at the backplane of the chassis - we should hook these channels up to the DAQ for long term monitoring.
  • The schematic claims "120mV/dBm" into 50ohms at these monitoring pins.
  • I measured the signal levels with a DMM (Teed with 50ohm), but couldn't really make the numbers jive - converting the measured backplane voltage into dBm of input power gives me an inferred power level that is ~5dBm higher than the actual measured power levels (measured with Agilent analyzer in Spectrum Analyzer mode).
• Looking at the time series of the ALS I and Q inputs, the signals are large, but we are well clear of saturating our 16-bit ADCs.
• In the brief periods when both beats were stable in amplitude (as judged by control room analyzer), the output of the Q quadrature of the phase tracker servo was ~12,000 cts - the number I am familiar with for the green days is ~2000cts - so naively, I would say we have ~6x the RF beat power from the Beat Mouth compared to green ALS.
• I didn't characterize the conversion efficiency of the demod boards so I don't have a V (IF)/V (RF) number at the moment.
• I confirmed that the various peaks seen in the X arm beat spectrum aren't seen in the control signal of the EX Green PDH, by looking at the spectrum on an SR785 (it is also supposedly recorded in the DAQ system, but I can't find the channel and the cable is labelled "GCX-PZT_OUT", which doesn't match any of our current channels).
  Note to self from the future: the relevant channels are: C1:ALS-X_ERR_MON_IN1 (green PDH error signal with x10 gain from an SR560) and C1:ALS-X_SLOW_SERVO_IN1 (green PDH control signal from monitor point - I believe this is DC coupled as this is the error signal to the slow EX laser PZT temp control). I've changed the cable labels at the X end to reflect this reality. At some point I will calibrate these to Hz.
• The control room analyzer signals come from the "RF mon" outputs on the demod board, which supposedly couple the RF input with gain of -23dBm. These are then routed reverse through a power splitter to combine the X and Y signals, which is then plugged into the HP analyzer. The problem is not local to this path, as during the "breathing" of the Y beat RF amplitude, I can see the Q output of the phase tracker also breathing.

Next steps (that I can think of, ideas welcome!):

1. For Problem #1 - usual debugging tactic of switching X and Y electronics paths to see if the problem lies in the light or in the electronics. If it is in the electronics, we can swap around at various points in the signal chain to try and isolate the problematic component.
2. For Problem #2 - hook up the backplane monitor channels to monitor RF amplitudes over time and see if the drifts are correlated with other channels.
3. There is evidence of some acoustic peaks, which are possibly originating from the fibers - need to track these down, but I think for a first pass to try and get the red ALS going, we shouldn't be bothered by these.

I swapped the inputs to the ZHL-3A at the PSL table - so now the X beat RF signals from the beat mouth are going through what was previously the Y arm ALS electronics. From Attachment #1, you can see that the Y arm beat is now noisier than the X. The ~5kHz peak has also vanished.

So I will pursue this strategy of switching to try and isolate where the problem lies...

Somebody had forgotten to turn the HEPA variac on the PSL table down. It was set at 70. I set it at 20, and there is already a huge difference in the ALS spectra