Now that we have all Satellite boxes working again, I've been working on trying to recover the DRMI 1f locking over the last couple of days, in preparation for getting back to DRFPMI locking. Given that the AS light levels have changed, I had to change the whitening gains on the AS55 and AS110 channels to take this into account. I found that I also had to tune a number of demod phases to get the lock going. I had some success with the locks tonight, but noticed that the lock would be lost when the MICH/SRCL boosts were triggered ON - when I turned off the triggering for these, the lock would hold for ~1min, but I couldn't get a loop shape measurement in tonight.

As an aside, we have noticed in the last couple of months glitchy behaviour in the ITMY UL shadow sensor PD output - qualitatively, these were similar to what was seen in the PRM sat. box, and since I was able to get that working again, I did a similar analysis on the ITMY sat. box today with the help of Ben's tester box. However, I found nothing obviously wrong, as I did for the PRM sat. box. Looking back at the trend, the glitchy behaviour seems to have stopped some days ago, the UL channel has been well behaved over the last week. Not sure what has changed, but we should keep an eye on this...

After much trial and error with whitening gains, demod phases and overall loop gains, I was finally able to lock the DRMI on both 1f and 3f signals! I went through things in the following order tonight:

1. Lock the arms, dither align
2. Lock the PRMI on carrier and dither align the PRM to get good alignment
3. Tried to lock the DRMI on 1f signals - this took a while. I realized the reason I had little to no success with this over the last few days was because I did not turn off the automatic unwhitening filter triggering on the demod screens. I had to tweak the SRM alignment while looking at the AS camera, and also adjust the demod phases for AS55 (MICH is on AS55Q) and REFL55 (SRCL is on REFL55I). Once I was able to get locks of a few seconds, I used the UGF servos to set the overall loop gain for MICH, PRCL and SRCL, after which I was able to revert the filter triggering to the usual settings
4. Once I adjusted the overall gains and demod phases, the DRMI locks were very stable - I left a lock alone for ~20mins, and then took loop shape measurements for all 3 loops
5. Then I decided to try transfering to 3f signals - I first averaged the IN1s to the 'B' channels for the 3 vertex DOFs using cds avg while locked on the 1f signals. I then set a ramp time of 5 seconds and turned the gain of the 'A' channels to 0 and 'B' channels to 1. The transition wasn't smooth in that the lock was broken but was reacquired in a couple of seconds.
6. The lock on 3f signals was also pretty stable, the current one has been going for >10 minutes and even when it loses lock, it is able to reacquire in a few seconds

I have noted all the settings I used tonight, I will post them tomorrow. I was planning to try a DRFPMI lock if I was successful with the DRMI earlier tonight, but I'm calling it a night for now. But I think the DRMI locking is now back to a reliable level, and we can push ahead with the full IFO lock...

It remains to update the auto-configure scripts to restore the optimized settings from tonight, I am leaving this to tomorrow as well...

Updated 16 Nov 2016 1130am

Settings used were as follows:

Nice job.

Over the weekend, I was successful in locking the DRMI with the arms held on ALS. The locks were fairly robust, lasting order of minutes, and was able to reacquire by itself when it lost the lock in <1min. I had to tweak the demod phases and loop gains further compared to the 1f lock with no arms, but eventually I was able to run a sensing matrix measurement as well. A summary of the steps I had to follow:

• Lock on 1f signals, no arms, and run sensing lines, adjust REFL33 and REFL 165 demod phases to align PRCL, MICH and SRCL as best as possible to REFL33I, REFL165Q and REFL165I respectively
• I also set the offsets to the 'B' inputs at this stage
• Lock arms on ALS, engage DRMI locking on 3f signals (the restore script resets some values like the 'B' channel offsets, so I modified the restore script to set the offsets I most recently measured)
• I was able to achieve short locks on the settings from the locking with no arms - I set the loop gains using the UGF servos and ran some sensing lines to get an idea of what the final demod phases should be
• Adjusted the demod phases, locked the DRMI again (with CARM offset = -4.0), and took another sensing matrix measurement (~2mins). The data was analyzed using the set of scripts EricQ has made for this purpose, here is the result from a lock yesterday evening (the radial axis is meant to be demod board output volts per meter but the calibration I used may be wrong)

I've updated the appropriate fields in the restore script. Now that the DRMI locking is somewhat stable again, I think the next step towards the full lock would be to zero the CARM offset and turning on the AO path.

On the downside, I noticed yesterday that ITMY UL shadow sensor readback was glitching again - for the locking yesterday, I simply held the output of that channel to the input matrix, which worked fine. I had already done some debugging on the Sat. Box with the help of the tester box, but unlike the PRM sat. box, I did not find anything obviously wrong with the ITMY one... I also ran into a CDS issue when I tried to run the script that sets the phase tracker UGF - the script reported that the channels it was supposed to read (the I and Q outputs of the ALS signal, e.g. C1:ALS-BEATX_FINE_I_OUT) did not exist. The same channels worked on dataviever though, so I am not sure what the problem was. Some time later, the script worked fine too. Something to look out for in the future I guess..

I've noticed that the glitchy behaviour in ITMY UL shadow sensor readback is back - as mentioned above, I looked at the Sat. Box and could not find anything wrong with it, perhaps I'll plug the tester box in over the Thanksgiving weekend and see if the glitches persist...

400 days plot. Satelite amp ITMY has been swapped with ETMY

Unlabeled sat.amps are labeled. This plot only makes sense if you know the Cuh-Razy sat amp locations.

Short summary:

• Looks like Satellite boxes are not to blame for glitchy behaviour of shadow sensor PD readouts
• Problem may lie at the PD whitening boards (D000210) or with the Contec binary output cards in c1sus
• Today evening, similar glitchy behaviour was observed in all MC1 PD readout channels, leading to frequent IMC unlocking. Cause unknown, although I did work at 1X5, 1X6 today, and pulled out the PD whitening board for ITMY which sits in the same eurocrate as that for MC1. MC2/MC3 do not show any glitches.

Detailed story below...

Part 1: Satellite box swap

Yesterday, I switched the ITMY and ETMY satellite boxes, to see if the problems we have been seeing with ITMY UL move with the box to ETMY. It did not, while ITMY UL remained glitchy (based on data from approximately 10pm PDT on 28Nov - 10am PDT 29 Nov). Along with the tabletop diagnosis I did with the tester box, I concluded that the satellite box is not to blame.

Part 2: Tracing the signal chain (actually this was part 3 chronologically but this is how it should have been done...)

So if the problem isn't with the OSEMs themselves or the satellite box, what is wrong? I attempted to trace the signal chain from the satellite box into our CDS system as best as I could. The suspension wiring diagram on our wiki page is (I think) a past incarnation. Of course putting together a new diagram was a monumental task I wasn't prepared to undertake tonight, but in the long run this may be helpful. I will put up a diagram of the part I did trace out tomorrow, but the relevant links for this discussion are as follows (? indicates I am unsure):

1. Sat box (?)--> D010069 via 64pin IDE connector --> D000210 via DB15 --> D990147 via 4pin LEMO connectors --> D080281 via DB25 --> ADC0 of c1sus
2. D000210 backplane --> cross-connect (mis)labelled "ITMX white" via IDE connector
3. c1sus CONTEC DO-32L-PE --> D080478 via DB37 --> BO0-1 --> cross-connect labelled "XY220 1Y4-33-16A" via IDE --> (?)  cross-connect (mis)labelled "ITMX white" via IDE connector

I have linked to the DCC page for the various parts where available. Unfortunately I can't locate (on new DCC or old or elog or wiki) drawings for D010069 (Satellite Amplifier Adapter Board), D080281 ("anti-aliasing interface)" or D080478 (which is the binary output breakout box). I have emailed Ben Abbott who may have access to some other archive - the diagrams would be useful as it is looking likely that the problem may lie with the binary output.

So presumably the first piece of electronics after the Satellite box is the PD whitening board. After placing tags on the 3 LEMOs and 1 DB15 cable plugged into this board, I pulled out the ITMY board to do some tabletop diagnosis in the afternoon around 2pm 29Nov.

Part 3: PD whitening board debugging

This particular board has been reported as problematic in the recent past. I started by inserting a tester board into the slot occupied by this board - the LEDs on the tester board suggested that power-supply from the backplane connectors were alright, confirmed with a DMM.

Looking at the board itself, C4 and C6 are tantalum capacitors, and I have faced problems with this type of capacitor in the past. In fact, on the corresponding MC3 board (which is the only one visible, I didn't want to pull out boards unnecessarily) have been replaced with electrolytic capacitors, which are presumably more reliable. In any case, these capacitors do not seem to be at any fault, the board receives +/-15 V as advertised.

The whitening switching is handled by the MAX333 - this is what I looked at next. This IC is essentially a quad SPDT switch, and a binary input supplied via the backplane connector serves to route the PD input either through a whitening filter, or bypass it via a unity gain buffer. The logic levels that effect the switching are +15V and 0V (and not the conventional 5V and 0V), but according to the MAX333 datasheet, this is fine. I looked at the supply voltage to all ICs on the board, DC levels seemed fine (as measured with a DMM) and I also looked at it on an oscilloscope, no glitches were seen in ~30sec viewing stretch. I did notice something peculiar in that with no input supplied to the MAX333 IC (i.e. the logic level should be 15V), the NO and NC terminals appear shorted when checked with a DMM. Zach has noticed something similar in the past, but Koji pointed out that the DMM can be fooled into thinking there is a short. Anyway, the real test was to pull the logic input of the MAX333 to 0, and look at the output, this is what I did next.

The schematic says the whitening filter has poles at 30,100Hz and a zero at 3 Hz. So I supplied as "PD input" a 12Hz 1Vpp sinewave - there should be a gain of ~x4 when this signal passes through the path with the whitening filter. I then applied a low frequency (0.1Hz) square wave (0-5V) to the "bypass" input, and looked at the output, and indeed saw the signal amplitude change by ~4x when the input to the switch was pulled low. This behaviour was confirmed on all five channels, there was no problem. I took transfer functions for all 5 channels (both at the "monitor" point on the backplane connector and on the front panel LEMOs), and they came out as expected (plot to be uploaded soon).

Next, I took the board back to the eurocrate. I first put in a tester box into the slot and measured the voltage levels on the backplane pins that are meant to trigger bypassing of the whitening stage, all the pins were at 0V. I am not sure if this is what is expected, I will have to look inside D080478 as there is no drawing for it. Note that these levels are set using a Contec binary output card. Then I attached the PD whitening board to the tester board, and measured the voltages at the "Input" pins of all the 5 SPDT switches used under 2 conditions - with the appropriate bit sent out via the Contec card set to 0 or 1 (using the button on the suspension MEDM screens). I confirmed using the BIO medm screen that the bit is indeed changing on the software side, but until I look at D080478, I am not sure how to verify the right voltage is being sent out, except to check at the pins on the MAX333. For this test, the UL channel was indeed anomalous - while the other 4 channels yielded 0V (whitening ON, bit=1) and 15V (whitening OFF, bit=0), the corresponding values for the UL channel were 12V and 10V.

I didn't really get any further than this tonight. But this still leaves unanswered questions - if the measured values are faithful, then the UL channel always bypasses the whitening stage. Can this explain the glitchy behaviour?

Part 4: MC1 troubles

At approximately 8pm, the IMC started losing lock far too often - see the attached StripTool trace. There was a good ~2hour stretch before that when I realigned the IMC, and it held lock, but something changed abruptly around 8pm. Looking at the IMC mirror OSEM PD signals, all 5 MC1 channels are glitching frequently. Indeed, almost every IMC lockloss in the attached StripTool is because of the MC1 PD readouts glitching, and subsequently, the damping loops applying a macroscopic drive to the optic which the FSS can't keep up with. Why has this surfaced now? The IMC satellite boxes were not touched anytime recently as far as I am aware. The MC1 PD whitening board sits in the same eurocrate I pulled the ITMY board out of, but squishing cables/pushing board in did not do anything to alleviate the situation. Moreover, MC2 and MC3 look fine, even though their PD whitening boards also sit in the same eurocrate. Because I was out of ideas, I (soft) restarted c1sus and all the models (the thinking being if something was wrong with the Contec boards, a restart may fix it), but there was no improvement. The last longish lock stretch was with the MC1 watchdog turned off, but as soon as I turned it back on the IMC lost lock shortly after.

I am leaving the autolocker off for the night, hopefully there is an easy fix for all of this...

[ericq, gautam]

To diagnose the glitches in OSEM readouts, we have removed one of the PCIE BO D37 to IDE50 adaptor boxes from 1X5. All the watchdogs were turned off, and the power to the unit was cut before the cables on the front panel were removed. I am working on the diagnosis, I will update more later in the evening. Note that according to the c1sus model, the box we removed supplies backplane logic inputs that control whitening for ITMX, ITMY, BS and PRM (in case anyone is wondering/needs to restore damping to any of these optics). The whitening settings for the IMC mirrors resides on the other unit in 1X5, and should not be affected.

As we suspected, the binary breakout board (D080478, no drawing available) is simply a bunch of tracks printed on the PCB to route the DB37 connector pins to two IDE50 connectors. There was no visible damage to any of the tracks (some photos uploaded to the 40m picasa). Further, I checked the continuity between pins that should be connected using a DMM.

I got a slightly better understanding of how the binary output signal chain is - the relevant pages are 44 and 48 in the CONTEC manual. The diagram on pg44 maps the pins on the DB37 connector, while the diagram on pg 48 maps how the switching actually occurs. The "load" in our case is the 4.99kohm resistor on the PD whitening board D000210. Following the logic in the diagram on pg48 is easy - setting a "high" bit in the software should pull the load resistor to 0V while setting a "low" bit keeps the load at 15V (so effectively the whole setup of CONTEC card + breakout board + pull-up resistor can be viewed as a simple NOT gate, with the software bit as the input, and the output connected to the "IN" pin of the MAX333).

Since I was satisfied with the physical condition of the BO breakout board, I re-installed the box on 1X5. Then, with the help of a breakout board, I diagnosed the situation further - I monitored the voltage to the pins on the backplane connector to the whitening boards while switching the MEDM switches to toggle the whitening state. For all channels except ITMY UL, the behaviour was as expected, in line with the preceeding paragraph - the voltage swings between ~0V and ~15V. As mentioned in my post yesterday, the ITMY UL channel remains dodgy, with voltages of 12.84V (bit=1) and 10.79V (bit=0). So unless I am missing something, this must point to a faulty CONTEC card? We do have spares, do we want to replace this? It also looks like this problem has been present since at least 2011...

In any case, why should this lead to ITMY UL glitching? According to the MAX333 datasheet, the switch wants "low"<0.8V and "high">2.4V - so even if the CONTEC card is malfunctioning and the output is toggling between these two states, the condition should be that the whitening stage is always bypassed for this channel. The bypassed route works just fine, I measured the transfer function and it is unity as expected.

So what could possibly be leading to the glitches? I doubt that replacing the BO card will solve this problem. One possibility that came up in today's meeting is that perhaps the +24V to the Sat. Box. (which is used to derive the OSEM LED drive current) may be glitching - of course we have no monitor for this, but given that all the Sat. Amp. Adaptor boards are on 1X5 near the Acromag, perhaps Lydia and Johannes can recommission the PSL diagnostic Aromag to a power supply monitoring Acromag?

What do these glitches look like anyway? Here is a few second snapshot from one of the many MC1 excursions from yesterday - the original glitch itself is very fast, and then that gives an impulse to the damping loop which eventually damps away.

And here is one from when there was a glitch when the tester box was plugged in to the ITMY signal chain (so we can rule out anything in the vacuum, and also the satellite box itself as the glitches seem to remain even when boxes are shuffled around, and don't migrate with the box). So even though the real glitch happens in the UL channel (note the y axes are very different for the channels), the UR, LR and LL channels also "feel" it. recall that this is with the tester box (so no damping loops involved), and the fact that the side channel is more immune to it than the others is hard to explain. Could this just be electrical cross-coupling?

Still beats me what in the signal chain could cause this problem.

Some good news - Koji was running some tests on the modified WFS demod board and locked the IMC for this. We noticed that MC1 seemed well behaved for extended periods of time unlike last night. I realigned the PMC and IMC, and we have been having lock streches of a few hours as we usually have. I looked at the MC1 OSEM PD readbacks during the couple of lock losses in the last few hours, and didn't notice anything dramatic . So if things remain in this state, at least we can do other stuff with the IFO... I have plugged in the ITMY sat. box again, but have left the watchdog disabled, lets see what the glitching situation is overnight... The original ITMY sat. box has been plugged into the ETMY DAQ signal chain with a tester box. The 3 day trend supports the hypothesis the sat. box is not to blame. So I am plugging the ETMY suspension back in as well...

I noticed 2 periods of frequent IMC locklosses on the StripTool trace, and so checked the MC1 PD readout channels to see if there were any coincident glitches. Turns out there wasnt BUT - the LR and UR signals had changed significantly over the last couple of days, which is when I've been working at 1X5. The fast LR readback was actually showing ~0, but the slow monitor channel had been steady so I suspected some cabling shenanigans.

Turns out, the problem was that the LEMO connector on the front of the MC1 whitening board had gotten jiggled ever so slightly - I re-jiggled it till the LR fast channel registered similar number of counts to the other channels. All looks good for now. For good measure, I checked the 3 day trend for the fast PD readback for all 8 SOS optics (40 channels in all, I didn't look at the ETMs as their whitening boards are at the ends), and everything looks okay... This while situation seems very precarious to me, perhaps we should have a more robust signal routing from the OSEMs to the DAQ that is more immune to cable touching etc...

For no apparent reason, the MC1 glitches are back. Nothing has been touched near the PD whitening chassis today, and the trend suggests the glitching started about 3 hours ago.. I had disabled the MC1 watchdog for a while to avoid the damping loop kicking the suspension around when these glitches occur, but have re-enabled it now. IMC is holding lock for some minutes... I was hoping to do another round of ringdowns tonight, but if this persists, its going to be difficult...

Gautam and Steve,

Our MCREFL rfpd C30642GH 2x2mm beeing investigated for burned spots.

Atm1,           unused -  brand new pd

Atm2,3,4       MCREFL in place was not moved

More pictures will be posted on 40m Picassa site later. 

I did a quick measurement of the beam size on the MC REFL PD today morning. I disabled the MC autolocker while this measurement was in progress. The measurement set up was as follows:

This way I was able to get right up to the heat sink - so this is approximately 2cm away from the active area of the PD. I could also measure the beam size in both the horizontal and vertical directions.

The measured and fitted data are:

The beam size is ~0.4mm in diameter, while the active area of the photodiode is 2mm in diameter according to the datasheet. So the beam is ~5x smaller than the active area of the PD. I couldn't find anything in the datasheet about what the damage threshold is in terms of incident optical power, but there is ~100mW on th MC REFL PD when the MC is unlocked, which corresponds to a peak intensity of ~1.7 W / mm^2...

Even though no optics were intentionally touched for this measurement, I quickly verified that the spot is centered on the MC REFL PD by looking at the DC output of the PD, and then re-enabled the autolocker.

Overall Design

A schematic of the overall subsystem diagran in attachment.

RF and Optical Connections

Starting at the top left corner is the diode laser module.  This laser has an input which allows it to be amplitude modulated.  The output of the laser is coupled into an optical fiber which is connectorized with an FC/APC connector and is connected to the input port of a 1 by 16 Optical Fiber Splitter. The Splitter produces 16 optical fiber outputs dividing the input laser power into 16 roughly equal optical optical fiber outputs.  These optical fibers are routed to the Photodiode Receivers (PD) which are the devices under test. All of the PDs are illuminated simultaneously with amplitude modulated light. The Optical Fiber outputs each have a collimating fiber telescope which is used to focus the light onto the PDs. Optical Fiber CH1 is routed to a broadband flat response reference photodiode which is used to provide a reference to the HP-4395A Network Analyzer.  The other Channel outputs are connected to an RF switch which can be programmed to select one of 16 inputs as the output.  The selected outputs can then be sent into channel A of the RF Network Analyzer. 

RF Switch

The RF switch consists of two 8 by 1 Multiplexers (National Instruments PXI-254x) slotted into a PXI Chassis (National Instruments PXI-1033).  The Multiplexers have 8 RF inputs and one RF output and can be programmed through the PXI Chassis to select one and only one of the 8 inputs to be routed to the RF output.) The first 8 Channels are connected to the first 8 inputs of the first Multiplexer.  The first Multiplexer’s output is then connected to the Channel 1 input of the second Multiplexer. The remaining PD outputs are connected to the remaining inputs of the second Multiplexer. The output of the second Multiplexer is connected to the A channel of the RF Network Analyzer.  Thus it is possible to select any one of the PD RF outputs for analysis.

Software

Something on this tomorrow.

Since the single arm locking and dither alignment seemed to work alright after the CDS overhaul, I decided to try some recycling cavity locking tonight.

• First, I locked single arms, ran dither alignment servos, and centered all test mass Oplevs. Note: the X arm dither alignment doesn't seem to work if we use the High-Gain Thorlabs PD as the Transmission PD. The BS loops just seem to pick up large offsets and the alignment actually degrades over a couple of minutes. This needs to be investigated.
• Next, to get good PRM alignment, I manually moved the EPICS sliders till the REFL spot became roughly centered on the CCD screen.
• Then I tried locking PRMI on carrier using the usual C1IFOConfigure script - the lock was caught within ~30 seconds.
• The PRCL and MICH dither servo scripts also ran fine.
  • Centered PRM Oplev.
• Next, I tried enabling the PRC angular feedforward.
  • OAF model does not automatically revert to its safe.snap configuration on model reboot, so I first manually did this such that the correct filter banks were enabled.
  • I was able to turn on the angular feedforward without disturbing the PRMI carrier lock. The angular motion of the POP spot on the CCD monitor was visibly reduced.
• At this point I decided to try DRMI locking.
  • I centered the beam on the AS PDs with the simple Michelson.
  • Centered the beam on the REFL PDs with PRM aligned and PRC flashing through resonances.
  • Restored SRM alignment by eye with EPICS sliders.
  • Cavity alignment seemed alright - so I tried to lock DRMI with the old settings (i.e. from DRMI 1f locking a couple of months ago). But I had no success.
  • The behaviour of REFL55 (used for SRCL control) has changed dramatically - the analog whitening gain for this PD used to be +18dB, but at this setting, there are frequent ADC overflows. I had to reduce the whitening gain to +6dB to stop the ADC overflows. I also checked to make sure that the whitening setting was "manual" and not triggered.

Why should this have changed? I was just on the AS table and did re-center the beam onto the REFL 55 RFPD, but I had also done this in April/May when I was last doing DRMI locking. But I can't explain the apparent factor of ~4 increase in light level. I think I have some measurements of the light levels at various PDs from April 2017, I will see how the present levels line up.

Of course dataviever won't cooperate when I am trying to monitor testpoints.

I may be missing something obvious, but I am quitting for tonight, will look into this more tomorrow.

Unrelated to this work: looking at the GTRY spot on the CCD monitor, there seems to be some excess angular motion. Not sure where this is coming from. In the past, this sort of problem has been symptomatic of something going wonky with the Oplev loops. But I took loop measurements for ITMY and ETMY PIT and YAW, they look normal. I will investigate further when I am doing some more ALS work.

1) Introduction

In brief, I trained a deep neural network (DNN) to recosntuct the cavity length, using as input only the transmitted power and the reflection PDH signals. The training was performed with simulated data, computed along 0.25s long trajectories sampled at 8kHz, with random ending point in the [-lambda/4, lambda/4] unique region and with random velocity.

The goal of thsi work is to validate the whole approach of length reconstruction witn DNN in the Fabry-Perot case, by comparing the DNN reconstruction with the ALS caivity lenght measurement. The final target is to deploy a system to lock PRMI and DRMI. Actually, the Fabry-Perot cavity problem is harder for a DNN: the cavity linewidth is quite narrow, forcing me to use very high sampling frequency (8kHz) to be able to capture a few samples at each resonance crossing. I'm using a recurrent neural network (RNN), in the input layers of the DNN, and this is traine using truncated backpropagation in time (TBPT): during training each layer of RNN is unrolled into as many copies as there are input time samples (8192 * 0.25 = 2048). So in practice I'm training a DNN with >2000 layers! The limit here is computational, mostly the GPU memory. That's why I'm not able to use longer data stretches.

But in brief, the DNN reconstruction is performing well for the first attempt.

2) Training simulation

In the results shown below, I'm using a pre-trained network with parameters that do not match very well the actual data, in particular for the distribution of mirror velocity and the sensing noises. I'm working on improving the training.

I used the following parameters for the Fabry-Perot cavity:

The uncertaint is assumed to be the 90% confidence level of a gaussian distribution. The DNN is trained on 100000 examples, each one a 0.25/8kHz long trajectory with random velocity between 0.1 and 5 um/s, and ending point distributed as follow: 33% uniform on the [-lambda/4, lambda/4] region, plus 33% gaussian distribution peaked at the center with 5 nm width. In addition there are 33% more static examples, distributed near the center. 

For each point along the trajectory, the signals TRA, POX11_I and POX11_Q are computed and used as input to the DNN.

3) Experimental data

Gautam collected about 10 minutes of data with the free swinging cavity, with ALS locked on the arm. Some more data were collected with the cavity driven, to increase the motion. I used the driven dataset in the analysis below.

3.1) ALS calibration

The ALS signal is calibrated in green Hz. After converting it to meters, I checked the calibration by measuring the distance between carrier peaks. It turned out that the ALS signal is undercalibrated by about 26%. After correcting for this, I found that there is a small non-linearity in the ALS response over multiple FSR. So I binned the ALS signal over the entire range and averaged the TRA power in each bin, to get the transmission signals as a function of ALS (in nm) below:

I used a peak detection algorithm to extract the carrier and 11 MHz sideband peaks, and compared them with the nominal positions. The difference between the expected and measured peak positions as a function of the ALS signal is shown below, with a quadratic fit that I used to improve the ALS calibration

The result is

The ALS calibrated z error from the peak position is of the order of 3 nm (one sigma)

3.2) Mirror velocity

Using the calibrated ALS signal, I computed the cavity length velocity. The histogram below shows that this is well described by a gaussian with width of about 3 um/s. In my DNN training I used a different velocity distribution, but this shouldn't have a big impact. I'm retraining with a different distirbution.

4) DNN results

The plot below shows a stretch of time domain DNN reconstruction, compared with the ALS calibrated signal. The DNN output is limited in the [-lambda/4, lambda/4] region, so the ALS signal is also wrapped in the same region. In general the DNN reconstruction follows reasonably well the real motion, mostly failing when the velocity is small and the cavity is simultanously out of resonance. This is a limitation that i see also in simulation, and it is due to the short training time of 0.25s.

I did not hand-pick a good period, this is representative of the average performance. To get a better understanding of the performance, here's a histogram of the error for 100 seconds of data:

The central peak was fitted with a gaussian, just to give a rough idea of its width, although the tails are much wider. A more interesting plot is the hisrogram below of the reconstructed position as a function of the ALS position, Ideally one would expect a perfect diagonal. The result isn't too far from the expectation:

The largest off diagonal peak is at (-27, 125) and marked with the red cross. Its origin is more clear in the plot below, which shows the mean, RMS and maximum error as a function of the cavity length. The second peak corresponds to where the 55 MHz sideband resonate. In my training model, there were no 55 MHz sidebands nor higher order modes. 

5) Conclusions and next steps

The DNN reconstruction performance is already quite good, considering that the DNN couldn't be trained optimally because of computation power limitations. This is a validation of the whole idea of training the DNN offline on a simulation and then deploy the system online.

I'm working to improve the results by

• training on a more realistic distribution of velocity
• adding the 55 MHz sidebands
• maybe adding HOMs
• tune the DNN architecture

However I won't spend too much time on this, since I think the idea has been already validated.

Phenomenal!

I tried some DRMI locking again tonight, but had no success. Here is the story.

• I started out by going to the AS table and measuring the light level on the REFL55 photodiode (with PRM aligned and the PRC flashing, but LSC disabled).
  • The Ophir power meter reads 13mW
  • The DC output of the photodiode shows ~500mV on an oscilloscope.
  • Both of these numbers line up well with measurements I made in April/May.
• Returned to the control room and aligned the IFO for DRMI locking - but LSC servos remained disabled.
  • At the nominal REFL55 whitening level of +18dB, the REFL 55 signals saturated the ADC (confirmed by looking at the traces on dataviewer).
  • But the signals still looked like PDH error signals.
  • Lowering the whitening gain to 6dB makes the PDH error signal horns peak around 20,000 counts.
  • Could this be indicative of problems with either the analog whitening gain switching or the LSC Demod Boards? To be investigated.
• Tried enabling LSC servos with same settings with which I had success right up till a couple of months ago, but had no success.
  • If it is true that the REFL55 signal is getting amplified because of some gain stage not being switched correctly, I should still have been able to lock the SRC with a lowered loop gain - but even lowering the gain by a factor of 10 had no effect on the locking success rate.

Looks like I will have to embark on the REFL55 LSC electronics investigation. I was able to successfully lock the PRC on carrier and sideband, and the Michelson lock also seems to work fine, all of which seem to point to a hardware problem with the REFL55 signal chain.

I did a quick check by switching the output of the REFL55 demod board to the inputs normally used by AS55 signals on the whitening board. Setting the whitening gain to +18dB for these channels had the same effect - ADC overflow galore. So looks like the whitening board isn't to blame. I will have to check the demod board out.

Update

I included the 55 MHz sideband and higher order modes in my training examples. To keep things simple, I just assumed there are higher order modes up to n+m=4 in the input beam. The power in each HOM is randomly chosen from a random gaussian distribution with width determined from experimental cavity scans. I used a value of 0.913+-0.01 rad for the Gouy phase (again estimated from cavity scans, but in reasonable agreement with the nominal radius of curvature of ETMX)

Results are improved. The plot belows show the performance of the neural network on 100s of experimental data

For reference, the plots below show the performance of the same network on simulated data (that includes sensing noise but no higher order modes)

truly.

Introduction

I trained a deep neural network (DNN) to reconstruct MICH and PRCL degrees of freedom in the PRMI configuration. For details on the DNN architecture please refer to G1701455 or G1701589. Or if you really want all the details you can look at the code. I used the following signals as input to the DNN: POPDC, POP22_Q, ASDC, REFL11_I/Q, REFL55_I/Q, AS55_I/Q.

Gautam took some PRMI data in free swinging and driven configuration:

• 1187819331 + 10mins: Free swinging PRMI (after first locking PRMI on carrier and dither aligning).
• 1187820070 + 5mins: PRM driven at low freq.
• 1187820446 + 5mins: BS driven at low freq.

In contrast to the Fabry-Perot cavity case, we don't have a direct measurement of the real PRCL/MICH degrees of freedom, so it's more difficult to assess if the DNN is working well.

Results

All MICH and PRCL values are wrapped into the unique region [-lambda/4, lambda/4]^2. It's even a bit more complicated than simpling wrapping. Indeed, MICH is periodic over [-lambda/2, lambda/2]. However, the Michelson interferometer reflectivity (as seen from PRC) in the first half of the segment is  the same as in the second half, except for a change in sign. This change of sign in Michelson reflectivity can be compensated by moving PRCL by lambda/4, thus generating a pi phase shift in the PRC round trip propagation that compensate for the MICH sign change. Therefore, the unit cell of unique values for all signals can be taken as [-lambda/4, lambda/4] x [-lambda/4, lambda/4] for MICH x PRCL. But when we hit the border of the MICH region, PRCL is also affected by addtion of lambda/4. Graphically, the square regions A B C below are all equivalent, as well as more that are not highlighted:

This makes it a bit hard to un-wrap the resonstructed signal, especially when you add in the factor that in the reconstruction the wrapping is "soft".

The plot below shows an example of the time domain reconstruction of MICH/PRCL during the free swinging period.

It's hard to tell if the positions look reasonable, with all the wrapping going on.

Two-dimensional maps of signals

Here's an attempt at validating the DNN reconstruction. Using the reconstructed MICH/PRCL signal, I can create a 2d map of the values of the optical signals. I binned the reconstructed MICH/PRCL in a 51x51 grid, and computed the mean value of all optical signals for each bin. The result is shown in the plot below, directly compared with the expectation from a simulation.

The power signals (POP_DC, AS_DC, PO22_Q) looks reasonably good. REFL11_I/Q also looks good (please note that due to an early mistake in my code, I reversed the convention for I/Q, so PRCL signal is maximized in Q instead than in I). The 55MHz signals look a bit less clear...

Steps forward

• I'm quite confident in the tuning of demodulation phase and signs for REFL11 and POP22, but less so for REFL55 and not sure at all for AS55. So it would be useful to measure a full sensing matrix of PRCL and MICH against those signals, to compare with my simulation
• I'm working on an idea to fine tune the DNN using the real interferometer data, more to follow when the idea crystallizes in a clear form.

Summary:

Today I tried debugging the mysterious increase in REFL55 signal levels in the DRMI configuration. I focused on the demod board, because last week, I had tried routing these signals through different channels on the whitening board, and saw the same effect. 

Based on my tests, everything on the Demod board seems to work as expected. I need to think more about what else could be happening here - specifically do a more direct test on the whitening board.

Details:

• The demod board is a modified D990511 (marked up schematic + high-res photo to follow).
• Initially, I tried probing the LO signal levels at various points with the board in the eurocrate itself, with the help of an extender card.
• But this wasn't very convenient, so I pulled the board out to the office area for more testing.
• The 55MHz LO signal going into the board is ~0dBm (measured with Agilent network analyzer)
• I used the active probe to check the LO levels at various points along the signal chain, which mostly consists of attenuators, ERA-5SM amplifiers, and some splitters/phase rotators.
• Everything seemed consistent with the expected levels based on "typical" numbers for gains and insertion losses cited in the datasheets for these devices.
• I couldn't directly measure the level at the LO input to the mixer, but measuring the input to the ERA-5SM immediately before the mixer, barring problems with this amplifier, the LO input of the mixer is being driven at >17dBm which is what it wants.
• Next, I decided to check the gain, gain imbalance and orthogonality of the demodulation.
• For this purpose, I restored the board to the Eurocrate, reconnected the LO input to the board, and used a second Marconi at a slightly offset frequency to drive the PD input at ~0dBm.
• Attachment #1 - The measured outputs look pretty balanced and orthogonal. The gain is consistent with an earlier measurement I made some months ago, when things were "normal". More bullets added after Rana's questions:
  • 300 MHz bandwidth oscilloscope used to acquire the data
  • I and Q outputs were from the daughter board
  • Data was acquired via ethernet data download utility
  • 20 MHz low-pass filter turned on on the Oscilloscope while downloading the data

All connections have been restored untill further debugging later in the evening.

[rana,gautam]

We did an ingenious checkup of the whitening board tonight.

• The board is D990694
• We made use of a tip-tilt DAC channel for this test (specifically TT1 UL, which is channel 1 on the AI board). We disconnected the cable going from the AI board to the TT coil driver board.
  • as opposed to using a function generator to drive the whitening filter, this approach allows us to not have to worry the changing offsets as we switch the whitening gain.
  • By using the CDS system to generate the signal and also demodulate it, we also don't have to worry about the drive and demod frequencies falling out of sync with each other.
• The test was done by injecting a low frequency (75.13 Hz, amplitude=0.1) excitation to this DAC channel, and using the LSC sensing matrix infrastructure to demodulate REFL55 I and Q at this frequency. Demod phases in these servos were adjusted such that the Q phase demodulated signal was minimized.
• An excitation was injected using awggui into TT1 UL exc channel.
• We then stepped the whitening gains for REFL55_I and REFL55_Q in 3dB steps, waiting 5 seconds for each step. Syntax is z step -s 5 C1:LSC-REFL55_I_WhiteGain +1.0,15 C1:LSC-REFL55_Q_WhiteGain +1.0,15
• Attachment #1 suggests that the whitening filter board is working as expected (each step is indeed 3dB and all steps are equal to the eye).
• Data + script used to generate this plot is in Attachment #2.

I've restored all connections at that we messed with at the LSC rack to their original positions.

The TT alignment seems to be drifting around more than usual after we disconnected one of the channels - when I came in today afternoon, the spot on the AS camera had drifted by ~1 spot diameter so I had to manually re-align TT1. 

After our Demod/Whitening electronics investigations suggested nothing obviously wrong, I decided to give DRMI locking another go tonight.

Surprisingly, there was no evidence of REFL55 behaving weirdly tonight, and I was able to easily lock the DRMI on 1f error signals using the recipe I've been using in the last few months.

Not sure what to make of all this .

I got in a ~15 minute lock, but I wasn't prepared to do any sort of characterization/ sensing / attempt to turn on coil-dewhitening, and I'm too tired to try again tonight. I was however able to whiten the error signals, as I have been able to do in the past. There is a ~45Hz bump in MICH that I haven't seen in the past.

I'll try and do some characterization tomorrow eve, but it's encouraging to at least get back to the pre-FB-failure state of locking.

Now that the DRMI locking seems to be repeatable again, I want to see if I can improve the measured MICH noise. Recall that the two dominant sources of noise were

1. BS Oplev loop A2L - this was the main noise between 30-60Hz.
2. DAC noise - this dominated between ~60-300Hz, since we were operating with the de-whitening filters off.

In preparation for some locking attempts today evening, I did the following:

1. Added steeper elliptic roll-off filters for the ITMX and ITMY Oplevs. This is necessary to allow the de-whitening filters to be turned on without railing the DAC.
2. Modified the BS Oplev loop to also have steeper high-frequency (>30Hz) roll off. The roll-off between 15-30Hz is slightly less steep as a result of this change.
3. Measured all Oplev loop TFs - UGFs are between 4 Hz and 5 Hz, phase margin is ~30degrees. I did not do any systematic optimization of this for today.
4. Went into the Foton filter banks for all the coil output filters, and modified the "Output" settings to be on "Input crossing", with a "Tolerance" of 10 and a "Timeout" of 3 seconds. These settings are to facilitate smooth transition between the two signal paths (without and with coil-dewhitening). The parameters chosen were arbitrary and not optimized in any systematic manner.
5. After making the above changes, I tried engaging the de-whitening filters on ITMX, ITMY and BS with the arms locked. In the past, I was unable to do this because of a number of issues - Oplev loop shapes and Foton settings among them. But today, the switching was smooth, the single arm locks weren't disturbed when I engaged the coil de-whitening.

Hopefully, I can successfully engage a similar transition tonight with the DRMI locked. The main difference compared to this daytime test is going to be that the MICH control signal is also going to be routed to the BS.

Tasks for tonight, if all goes well:

1. Lock DRMI.
2. Use UGF servos to set the overall loop gains for DRMI DoFs.
3. Reduce PRCL->MICH and SRCL->MICH coupling.
4. Measure loop shapes of all DRMI DoFs.
5. Make sensing matrix measurement.
6. Engage coil-dewhitening, download data, make NB.

Unrelated to this work: the PMC was locked near the upper rail of the PZT, so I re-locked it closer to the middle of the range.

not immediately necessary, since you have already got it sort of working, but one of these days we should optimize this for real. In the past, we used to do this by putting a o'scope on the coil Vmon during the switching to catch the transient w/ triggering. We download the data/picture via ethernet. Run for loop on tolerance to see what's what.

Summary:

Tonight, I was able to lock the DRMI, turn on the whitening filters for the sensing PDs, and also turn on the coil de-whitening filters for ITMX, ITMY and BS. However, I didn't see the expected improvement in the MICH spectrum between ~50-300 Hz . Sad.

Details:

I basically went through the list of tasks I made in the previous elog. Some notes:

• The UGF servos suggested that I had to lower the SRCL gain. I lowered it from -0.055 to -0.025. OLTF measurement using In1/In2 method suggested UGF ~120Hz. I don't know why this should be. Plot to be uploaded later.
• Since we aren't actuating on the ITMs, I was able to leave their coils de-whitened all the time.
• For the BS, it was trickier - I had to play around a little with the "Tolerance" setting in Foton while looking at transients (using DTT, not a scope for now) while switching the filters.
• This transition isn't so robust yet - but eventually I found a setting that worked, and I was able to successfully turn on the de-whitening thrice tonight (but also failed about the same number of times). [GV Oct 6 2017: Remember that the PD whitening has to be turned on for this transition to be successful - otherwise the RMS from the high frequencies saturate the DAC.]
• The locks were pretty stable. One was ~10mins, one was ~15mins, and I broke both deliberately because I was out of ideas as to why the part of the MICH error signal spectrum that I thought was due to DAC noise didn't improve.
• I've made a bunch of shell scripts to help with the various switchings - but now that I think of it, I should make these python scripts.

Attachment #1: Comparison of MICH_ERR with and without the BS de-whitening. Note that the two ITMs have their coils de-whitened in both sets of traces.

Attachment #2: Spectra of MICH output and one of the BS coil outputs in both states. The DAC RMS increases by ~30x when the de-whitening is engaged, but is still well within limits.

So it looks like the switching of paths is happening correctly. The "CDS BIO STATUS" MEDM screen also shows the appropriate bits toggling when I turn the de-whitening on/off. There is no broadband coherence with MCF between 50-300 Hz so it seems unlikely that this could be frequency noise.

Clearly I am missing something. But anyways I have a good amount of data, may be useful to put together the post CDS/electronics modification DRMI noise budget. More analysis to follow.

This is an update on the results already presented earlier (refer to elog 13274 for more introductory details). I improved significantly the results with the following tricks:

• I retuned the demodulation phase of AS55, this time ensuring that the (alleged) MICH motion is visible mostly in Q when crossing a carrier resonance. Further fine tunings of phases will be possible once we have a measurement of the length optical matrix

• I fine tuned the netwrok by training it again using the real data. The ides is the following. I started with the network trained on the simulated data, and froze the parameters of the input recurrent layers. I fed the real signal to the network, computed the reconstructed PRCL/MICH, and fed them to my PRMI model to compute simulated signals. I allowed some of the parameters of the models to vary (expecially demodulation phases). I then trained again the network by trying to match the model predicted signals with the real input signals. I allowed only the parameters of the fully connected layers to vary (mostly for technical reasons, I'm working on re-training also the recurrent layers)

An example of time domain reconstruction is visible below. It already looks better than the old results:

As before, to better evaluate the performance I plotted averaged values of the real signals as a function of the reconstructed MICH and PRCL positions. The results are compared with simulation below. They match quite well (left real data, right simualtion expectation)

One thing to better understand is that MICH seems to be somewhat compressed: most of the output values are between -100 and +100 nm, instead of the expected -lambda/4, lambda/4. The reason is still unclear to me. It might be a bug that I haven't been able to track down yet.

Summary:

Rana suggested checking if the coil de-whitening switching is actually happening in the analog path. I repeated the test detailed here. Attachments #1 and #2 suggest that all the coils for the BS and ITMs are indeed switching .

Details:

• The motivation behind this test was the following - the analog path switching is done by applying some logic voltage to a switch, but if this voltage is common among many switches, the hypothesis was that perhaps individual switches were not getting the required voltage to engage the switching.
• This time FM9 (simulated de-whitening) and FM10 (inverse de-whitening) in the coil output filter modules turned off, so as to maintain a flat TF in the digital domain, but engage the de-whitened analog path (turning off FM9 is supposed to do this).
• There is poor coherence in the measurement above 40Hz so the data there should be neglected. It is hard to get a good measurement at higher frequencies because of the pendulum TF + heavy low pass filtering from the analog de-whitening path.
• But between 10-40Hz, we already see the analog de-whitening TF in the measurement.
• For comparison, I have plotted the measured pendulum TFs for one of the coils from an earlier test (all the coils were roughly at the same level).

So it would seem that there is some other noise which has a 1/f^2 shape and is at the same level we expected the DAC noise to be at. Rana suggested checking coherence with MC transmission to see if this could be laser intensity noise.

I also want to re-do the actuator calibrations for the vertex optics again before re-posting the revised noise budget.

Introduction

This is an update of my previous reports on applications of deep learning to the reconstruction of PRMI degrees of freedom (MICH/PRCL) from real free swinging data. The results shown here are improved with respect to elog 13274 and 13294. The training is performed in two steps, the first one using simulated data, and the second one fine tuning the parameters on real data.

First step: training with simulation

This step is exactly the same already described in the previous entries and in my talks at the CSWG and LVC. For details on the DNN architecture please refer to G1701455 or G1701589. Or if you really want all the details you can look at the code. I used the following signals as input to the DNN: POPDC, POP22_Q, ASDC, REFL11_I/Q, REFL55_I/Q, AS55_I/Q. The network is trained using linear trajectories in the PRCL/MICH space, and signals obtained from a model that simulates the PRMI behavior in the plane wave approximation. A total of 150000 trajectories are used. The model includes uncertainties in all the optical parameters of the 40m PRMI configuration, so that the optical signals for each trajectory are actually computed using random optical parameteres, drwn from gaussian distributions with proper mean and width. Also, white random gaussian sensing noise is added to all signals with levels comparable to the measured sensing noise.

The typical performance on real data of a network pre-trained in this way was already described in elog 13274, and although being reasoble, it was not too good.

Second step: training with real data

Real free swinging data is used in this step. I fine tuned the demodulation phases of the real signals. Please note that due to an old mistake, my convention for phases is 90 degrees off, so for example REFL11 is tuned such that PRCL is maximized in Q instead of I. Regardless of this convention confusion, here's how I tuned the phases:

• REFL11: PRCL is all in Q when crossing the carrier resonance
• REFL55: PRCL is all in Q when crossing the carrier resonance
• AS55: MICH is all in Q when crossing the PRCL carrier resonance
• POP22: signal peaking in Q when crossing carrier or sideband resonances. Carrier resonance crossing gives positive sign

Then I built the following training architecture. The neural network takes the real signals and produces estimates of PRCL and MICH for each time sample. Those estimates are used as the input for the PRMI model, to produce the corresponding simulated optical signals. My cost function is the squared difference of the simulated versus real signals. The training data is generated from the real signals, by selection 100000 random 0.25s long chunks: the history of real signal over the whole 0.25s is used as input, and only the last sample is used for the cost function computation. The weights and biases of the neural network, as well as the model parameters are allowed to change during the learning process. The model parameters are regularized to suppress large deviations from the nominal values.

One side note here. At first sight it might seems weird that I'm actually fedding as input the last sample and at the same time using it as the reference for the loss function. However, you have to remember that there is no "direct" path from input to output: instead all goes through the estimated MICH/PRCL degrees of freedom, and the optical model. So this actually forces the network to tune the reconstruction to the model. This approach is very similar to the auto-encoder architectures used in unsupervised feature learning in image recognition.

Results

After trainng the network with the two previous steps, I can produce time domain plots like the one below, which show MICH and PRCL signals behaving reasonably well:

To get a feeling of how good the reconstruction is, I produced the 2d maps shown below. I divided the MICH/PRCL plane in 51x51 bins, and averaged the real optical signals with binning determined by the reconstructed MICH and PRCL degrees of freedom. For comparison the expected simulation results are shown. I would say that reconstructed and simulated results match quite well. It looks like MICH reconstruction is still a bit "compressed", but this should not be a big issue, since it should still work for lock acquisition.

Next steps

There a few things that can be done to futher tune the network. Those are mostly details, and I don't expect significant improvements. However, I think the results are good enough to move on to the next step, which is the on-line implementation of the neural network in the real time system.

I've been working on analyzing the data from the DRMI locks last week.

Here are the results of the sensing measurement.

Details:

1. The sensing measurement is done by using the existing sensing matrix infrastructure to drive the actuators for the various DoFs at specific frequencies (notches at these frequencies are turned on in the control loops during the measurement).
2. All the analysis is done offline - I just note down the times at which the sensing lines are turned on and then download the data later. The amplitudes of the oscillators are chosen by looking at the LSC PD error signal spectra "live" in DTT, and by increasing the amplitude until the peak height is ~10x above the nominal level around that frequency. This analysis was done on ~600seconds of data.
3. The actual sensing elements in the various PDs are calculated as follows:
   • Calculate the Fourier coefficients at the excitation frequency using the definition of the complex DFT in both the LSC PD signal and the actuator signal (both are in counts). Windowing is "Tukey", and FFT length used is 1 second.
   • Take their ratio
   • Convert to suitable units (in this case V/m) knowing (i) The actuator discriminant in cts/m and (ii) the cts/V ADC calibration factor. Any whitening gain on the PD is taken into account as well.
   • If required, we can convert this to W/m as well, knowing (i) the PD responsivity and (ii) the demodulation chain gain.
   • Most of this stuff has been scripted by EricQ and is maintained in the pynoisesub git repo.

The plotting utility is a work in progress - I've basically adapted EricQs scripts and added a few features like plotting the uncertainties in magnitude and phase of the calculated sensing elements. Possible further stuff to implement:

• Only plot those elements which have good coherence in the measurement data. At present, the scripts check the coherence and prompt the user if there is poor coherence in a particular channel, but no vetos are done.
• The uncertainty calculation is done rather naively now - it is just the standard deviation in the fourier coefficient determined from various bins. I am told that Bendat and Piersol has the required math. It would be good to also incorporate the uncertainties in the actuator calibration. These are calculated using the python uncertainties package for now.
• Print a summary of the parameters used in the calculation, as well as sensing elements + uncertainty in cts/m, V/m and W/m, on a separate page.
• Some aesthetics can be improved - I've had some trouble getting the tick intervals to cooperate so I left it as is for the moment.

Also, the value I've used for the BS actuator calibration is not a measured one - rather, I estimated what it will be by scaling the old value by the same ratio which the ITMs have changed by post de-whitening board mods. The ITM actuator coefficients were recently  measured here. I will re-do the BS calibrations over the weekend.

Noise budgeting to follow - it looks like I didn't set the AS55 demod phase to the previously determined optimal value of -82degrees, I had left it at -42 degrees. To be fixed for the next round of locking.

I downloaded a segment of data from the time when the DRMI was locked with the BS and ITM coil driver de-whitening switched on, and looked at coherence between MC transmission and the MICH error signal. Attachment #1 doesn't show any broadband high coherence between 60-300Hz, so it cannot explain the noise in the full range between 60-300Hz. 

The DQ channel for the MC transmission is recorded at 1024 kHz, so to calculate the coherence, I had to decimate the 16K MICH data. 

Since we have the AOM installed, I suppose we can actually measure the intensity noise coupling to MICH by driving a line in the AOM. 

I also checked for coherence in the 60-300Hz band between MICH/PRCL and MICH/SRCL, and didn't see any appreciable coherence. Need to think about this more.

The absence of evidence is not evidence of absence.

I've been working on setting up some scripts for measuring the DAC noise.

In all the DRMI noise budgets I've posted, the coil-driver noise contribution has been based on this measurement, which could be improved in a couple of ways:

• The measurement was made at the output of the AI board - we can make the measurement at the output of the coil driver board, which will be a closer reflection of the actual current noise at the OSEM coils.
• The measurement was made by driving the DAC with shaped random noise - but we can record the signal to the coils during a lock and make the noise measurement by using awg to drive the coil with this signal, with elliptic bandstops at appropriate frequencies to reveal the electronics noise.

1. The IN1 signals to the coils aren't DQ-ed, but ideally this is the signal we want to inject into the coil_EXC channel for this measurement - so I re-locked the DRMI a couple of nights ago and downloaded the coil IN1 channel data for ~5mins for the ITMs and BS.
2. AWGGUI supposedly has a feature that allows you to drive an EXC channel with an arbitrary signal - but I couldn't figure out how to get this working. I did find some examples of this kind of application using the Python awg packages, so I cobbled together some scripts that allows me to drive some channels and place elliptic bandstop filters as I required. 
3. I wasted quite a bit of time trying to implement these signals in Python using available scipy functions, on account of me being a DSP n00b . When trying to design discrete-time filters, of course numerical precision errors become important. Initially I was trying to do everything in the "Transfer function (numerator-denominator)" basis, but as Rana pointed out, the way to go is using SOSs. Fortunately, this is a simple additional argument to the relevant python functions, after which elliptic bandstop filter design was trivial.
4. The actual test was done as follows:
   • Save EPICS PIT/YAW offsets, set them to 0, disable Oplev servos, and then shut down optic watchdog once the optic is somewhat damped. This is to avoid the optics getting a large kick when disconnecting the DB15 connector from the coil driver board output.
   • Disconnect above-mentioned DB15 connector from the appropriate coil driver board output.
   • Turn off inputs to coils in filter module EPICs screens. Since the full signal (local damping servo output + Oplev servo output + LSC servo output) to the coil during a DRMI lock will be injected as an excitation, we don't need any other input. 
   • Use scripts (which I will upload to a git repo soon) to set up the appropriate excitation.
   • To measure the spectrum, I used a DB15 breakout board with test-points soldered on and some mini-grabber-to-BNC adaptors, in order to interface the SR785 to the coil driver output. We can use the two input channels of the SR785 to simultaneously measure two coil driver board output channels to save some time.
   • Take a measurement of the SR785 noise (at the appropriate "Input Range" setting) with inputs terminated to estimate the analyzer noise floor.
   • Just for kicks, I made the measurement with the de-whitening both OFF/ON.

I only managed to get in measurements for the BS and ITMX today. ITMY to be measured later, and data/analysis to follow.

The ITMX and BS alignments have been restored after this work in case anyone else wants to work with the IFO.

Some slow machine reboots were required today - c1susaux was down, and later, the MC autolocker got stuck because of c1iool0 being unresponsive. I thought we had removed all dependency of the autolocker on c1iool0 when we moved the "IFO-STATE" EPICS variable to the c1ioo model, but clearly there is still some dependancy. To be investigated.

Attachment #1: Summary of results of measurements made on Friday. There is a lot in this plot, here is a breakdown:

• I drove the excitation points of the coil output filter banks with raw time-series data downloaded during a DRMI lock with pyawg. Today during the meeting, Rana pointed out that we could just acquire median (as opposed to mean since the former is more immune to glitches during the averaging process) spectra during a lock, and then do the ifft in python to generate time series data for pyawg. Another advantage of doing it this way is that we don't need to store a large (~200MB in my case) file of 16k data for numerous channels. But since I already had this file, I decided against changing the methodology for this round of tests. Time series plots of the signals do not show any large glitches.
• The SR785 was used in dual channel mode to acquire spectra from 2 coil driver outputs simultaneously, in the interest of saving time. Input range was set to -32dbVpk, AC coupled, which was the smallest value that worked for the given signal profile. Spectra were taken from DC-200Hz, with 801 points, 25 averages. The DB15 output of the coil driver board was connected to a DB15 breakout board, and then a BNC->Pomona mini-grabber adapter was used to connect to the SR785 input. The newly acquired linear power supplies for the GPIB box mean that spurious 60Hz harmonics were not present. 
• Initially, I had planned to enable various bandstops from 20Hz-200Hz, to get a more complete profile of the noise. But in the end, I only used two elliptic bandstops (6th order, 60dB stopband attenuation): 60-90Hz, for which data is plotted in red and 90-200Hz, for which data is plotted in green. 
• I've used the same noise model as I used here, plotted in dashed grey (summed with SR785 noise at the above input range, with input terminated via 50ohm terminator) - but had to tweak the parameters to get the curve to line up with the measurement. It looks like there is considerable variation between DAC channels, and certainly between the ITMX channels and the BS channels as groups.
• I took the measurement in two conditions - with the coil de-whitening off (left column) and coil de-whitening on (right column). Note that the input to the excitation was acquired at the IN1 of the relevant filter bank, and since the de-whitening happens downstream of this, we don't have to do anything special.
• In the right column, I have also plotted the LISO modelled noise, which was shown to match well with the measured curve, admittedly only for one channel (for the coil driver alone, so I am not taking into account the noise of the de-whitening board - I will fix this once I dig up that data).

Some remarks:

1. According to this measurement, the de-whitening filters are the same on the ITMX channels and BS channels. So I don't understand the difference in the right column for BS and ITMX channels.
2. While there is considerable variation between channels and also between ITMX and BS, there is certainly >6dB of reduction in the DAC noise when the de-whitening is engaged. However, no improvement was seen in the MICH error signal spectrum between 60-300Hz. So we have to continue to investigate other noises that can explain the noise in that band.
3. Also, the realized improvement in DAC noise by turning on the coil de-whitening seems marginal - the low pass has gain of ~-80dB at 100Hz, but we seem to be hitting some sort of electronics noise in all channels at the level of ~100nV/rtHz (assuming the actual DAC noise doesn't degrade significantly when the digital simulated de-whitening filter is engaged).
4. It remains to do the test for the ITMY channels.
5. It would be useful to visualize the incoherent sum of all these channels - this is what should go into the MICH displacement NB. To be added.
6. I'm currently loading pyawg from my user directory. Need to figure out a place to put this and add it to $PATH.

Data + code for this plot will be attached later.

Since you're monitoring two channels simultaneously, you could try subtracting them, as an alternative to carving out bandstops.

1. Drive both channels with the same time series
2. Tweak the filter module gains if needed to equalize the analog outputs
3. Apply SR785 user math to subtract the two channels (or A-B mode of a single input, if you're not using that already?)
4. Measure the residual, which should be the incoherent part containing DAC + coil driver noise

Subtraction can conceal certain annoying effects (like numerical noise or level crossing glitches) that remain coherent for two identical outputs. It might be worth experimenting with a differential offset or sinusoid, to try to break up that kind of coherence if it exists.

I am running some more measurements of the DAC noise, for which I've shut down the BS watchdog. Some of the cables on the coil driver side have been disconnected.

I will restore these tomorrow.

As Rana pointed out to me, one important fact to keep in mind w.r.t. DAC noise is that it can be non-linear. So the RMS of the DAC noise in a higher frequency band (say 60-100Hz) can be affected by the RMS of the requested DAC signal in some lower frequency band (say 10-20Hz). One test to see if this hypothesis can explain the difference @100Hz between the ITMX channels and BS channels I observed a couple of days ago is to see if the noise around 100Hz becomes lower when I enable a 20-40Hz bandstop in the digital signal chain.

BS connections and damping restored.

GV Oct 6: This coupling is probably not correct - Finesse outputs TF magnitude in units of W/W, and not W/RIN. 

Since I was foiled (by lack of DAC) in my attempt to measure the coupling of laser intensity noise to MICH in the DRMI (no arms) configuration, I decided to try understanding the effect with a simulation.

For this purpose, I used my DRMI Finesse model - this had mirror positions tuned for locking and photodiode demod phases tuned to give a sensing matrix model that wasn't too far from an actual measurement (within factor of a few). So the model seems okay for a first pass at estimating this coupling.

Measuring transfer functions in Finesse is straightforward - use the fsig command to modulate some quantity (in this case the input beam intensity), and use the pd2 detector to demodulate the effect of this modulation at the port of interest (in this case AS55_Q).

**Note that to apply a modulation to an input beam (i.e. Laser) in Finesse, the keyword for the "type" argument given to fsig is "amp" and not "amplitude" as the manual would had me believe. In fact, there seem to be quite a few such caveats. The best way to figure this out is to go to the pykat installation directory, find the file components.py, and look for the fsig_name for the component of interest. It is also indicated in the same file, via the canFsig argument, if that property of the component can be modulated for transfer function measurements.  

Attachment #1 shows the result of such a sweep.

To estimate what the actual contribution to the displacement noise is, I used the DQ-ed MC transmission (recorded at 1024Hz) from the DRMI lock, computed the ASD using scipy.signal.welch, divided by the nominal MC transmission of ~15,000 counts to convert to RIN/rtHz. The RIN was then multiplied by the above calculated coupling function, and divided by the sensing matrix element for AS55_Q (in units of W/m) to give the curve shown in Attachment #2. If we believe the simulation, then Laser Intensity Noise shouldn't be the limiting noise between 10Hz-1kHz. 

I will of course measure the actual coupling and see how it lines up with Attachment #1 - would be a nice additional validation of the Finesse model. I will also try using the Finesse model to estimate some other coupling transfer functions (e.g. Laser Frequency Noise, Oscillator Noise).

I've located the Stanford Research FS725 Rb reference unit. The question is where to put it. This afternoon Steve and I put it inside the little electronics rack next to 1X3, but in hindsight, this probably isn't such a great place for a timing reference as there are a bunch of Sorensen power supplies in there (and presumably the accompanying harmonics from these switching supplies). 

The unit itself was repaired in 2015, and powering it on, it locked to the internal reference within a few minutes as prescribed in the manual. 

In the end I decided to access the available spare DAC channels via the C1ASS model - for this purpose, I added a namespace block "TEST" in the C1ASS simulink model, which is a SISO block. Inside is just a single CDS filter module. My idea is to use the EXC of this filter module to inject excitations for measuring various couplings. Rather than have a simple testpoint, we also have the option of adding in some filter shapes in the filter module which could possibly allow a more direct read-off of some coupling TF. Recompiling the model went smooth - there was a crash earlier in the day which required me to hard-reboot c1lsc (and also restart all models on c1sus and c1ioo but no reboots necessary for those machines).

Note that to get the newly added channels to show up in the channel lists in DTT/AWGGUI etc, you need to ssh into fb1 and restart the daqd processes via sudo systemctl restart daqd_*. If I remember right, it used to be enough to do telnet fb 8088 followed by shutdown. This is no longer sufficient.

It took me a while to get the DRMI locking going again. The model restarts earlier in the evening had changed a bunch of EPICS channel settings (and out config scripts don't catch all of these settings). In particular, I forgot to re-enable the x3 digital gain for the ITMs, BS and SRM (necessitated by removing an analog x3 gain on the de-whitening boards). I was hesitant to spend time re-adjusting all damping / oplev loop gains because if we change the series resistor on the coil driver board, we will have to do this again. I also didn't want this arbitrary FM to be enabled in the SDF safe.snap. But maybe it's worth doing it anyways - if nothing it'll be good practise.

Once I hunted down all the setting diffs and tweaked alignment, the DRMI locks were pretty robust.

I had hoped to make some of these TF measurements tonight. But I realized I needed to look up a bunch of stuff in manuals/datasheets, and think about these measurements a little. I wasn't sure if the DW/AI board could drive a signal over 40m of BNC cabling so I added an SR560 (DC coupled, gain=1, low noise mode, 50ohm output used) to buffer the output. The Marconi's external modulation input is high impedance (100k) but for the AOM driver we want 50ohm. For the Marconi, the external input accepts 1Vrms max, while for the AOM driver, we want to drive a signal between 0V and 1V at most.

The general measurement setup is schematically shown in Fig 1. Questions to address:

• What happens if we apply a negative voltage to the input of the AOM driver? What is the damage threshold? Do we have to worry about SR560 offset level?
• Is there a way to dynamically adjust the offset in DTT such that we can have different amplitude signals at different frequencies (usually done by specifying an envelope in DTT) but still satisfy the requirement that the entire signal lie between 0-1V?
• For the Laser Intensity noise -> MICH coupling TF measurement, I guess we can use the AOM to inject an excitation, and measure the ratio of the response in MC_TRANS and in MICH_IN1. Then we multiply the in-loop MC_TRANS spectrum by the magnitude of this TF to get the Laser Intensity Noise contribution to MICH.
• The Laser Frequency Noise coupling should be negligible in MICH - but the measurement principle should be the same. Drive the AO input of the Mode Cleaner Servo board from the DAC, look at ratio of response in MICH_IN1 and MC_F. Multiply the DRMI in-lock MC_F spectrum by this TF.
• The oscillator noise seems more tricky to me (also Finesse modeling suggests this may be the most significant of the 3 couplings described in this elog, though I may just be computing the coupling in Finesse wrongly)
  • I don't understand all the External Modulation options specified in the manual.
  • DC? AC? FM? PM? AM? Need to figure out what is the right settings to use.
  • I'm not sure how independent the various modulations will be - i.e. if I select PM, how much AM is induced as a result of me driving the EXT MOD input?
  • What is the right level of excitation drive? I tried this a bunch of times tonight - set the PM range to 0.1rad (for the full scale 1Vrms sine wave input), but with an excitation of just a few counts, already saw non-lineaer coupling in MICH_IN1 which probably means I'm driving this too hard.
  • This measurement needs a bit more algebra. We have an estimate of the Marconi phase noise from Rana (is this the right one to use?). But the "Transfer Function" we'd measure is cts in MICH_IN1 in response to counts to Marconi via the signal chain in Attachment #1. So we'd need to know (and divide out) the AI/DW board TF, and the Marconi's TF, which the datasheet suggests has a lower 3dB frequency of 100Hz (assuming SR560 and cable can be treated as flat).
  • A simpler test may be to just hook up the Marconi to the Rb standard, and the Rb to 1pps from GPS, and look for a change in the MICH noise.

Am I missing something?

[steve, gautam]

1. We installed the FS725 on the shelf inside the PSL enclosure - see Attachment #1.
2. We ran a long BNC cable (labelled "GPS 1pps" on both ends) from 1X7 to the PSL enclosure - this was to pipe the 1PPS signal from the GPS timing unit (EndRun Technologies Tempus LX) rear panel (50 ohm output according to the datasheet) to the 1PPS input of the FS725 (high impedance). See Attachments #2. Note that the 1pps output was already tee'd on the rear panel. One port of the tee was unused (this now goes to the FS725) while the other was going to the 1PPS input of the Master Timing Sequencer (D050239), so I decided that there was no need to tee the 1pps input of the FS725 with a 50ohm terminator. In a few minutes, the Rb standard indicated that it was locked to its internal reference, and also to the external 1pps input (see Attachment #1). 
3. We ran a long BNC cable (labelled "Rb 10MHz" on both ends) from the 10MHz output of the FS725 (50 ohm output impedance),  in the PSL enclosure to the rear BNC "FREQ_STD IN/OUT" BNC connector of the Marconi (1kohm input impedance). Changed the frequency reference setting on the Marconi to "External Direct". The FS725 datasheet recommends terminating the load with a 50ohm inline terminator, I have not yet done this (see Attachment #3). Is it appropriate to use a Balun (FTB-1-1) here? This would avoid ground loops between the Marconi and the FS725, and also make the load seen by the FS725 50ohms. 
4. Found that there was an unused long cable from the PSL enclosure to the 1X2 electronics rack. We re-purposed this to drive the AOM driver via the DAC output in 1Y2. The cable is labelled "AOM driver" on both ends. This was to facilitate measurement of the coupling of laser intensity noise to AS55_Q in a DRMI lock.
5. Removed 2 long cables between 1X7 and 1X2 that weren't connected to anything.
6. Re-arranged the DC bench supply on the shelf in the PSL enclosure, whose only purpose seems to be to supply 12V to a fan attached to the rear of the PSL NPRO controller. Seems to be a waste of space! The fan was momentarily disconnected but has since been reconnected and is spinning again.
7. Removed a couple of unused power cables from the mess on the shelf in the PSL enclosure. Also removed an unused Sony Video Squential Switcher YS-S6 from the PSL enclosure. 

Steve, can you please connect this fan to the rack power and remove this extra power supply?

[gabriele, gautam]

Gabriele had prepared a C code implementation of his NN for MICH/PRCL state estimation. He had been trying to get it going on some of the machines in WB, but was unsuccessful. The version of RCG he was trying to compile and run the code on was rather dated so we decided to give it a whirl on our new RCG3.4 here at the 40m. Just noting down stuff we tried here:

• Code has been installed at /opt/rtcds/userapps/release/cds/c1/src/nn.This is to facilitate compilation by the RCG.
• There is also a simulink block diagram (x3tst.mdl) in there which we copied and pasted into c1pem. Changed the appropriate paths in the C-Code block to point to the location in the previous bullet point.
• c1pem was chosen for this test as it runs at 2k which is what the network is designed for.
• Since we were running the test on c1sus and expected the machine to crash, I shutdown all the watchdogs for the test.
• Code compiled without any problems (i.e. rtcds make c1pem and rtcds install c1pem executed successfully). There were some warning messages related to C-Code blocks but these are not new, they show up in all models in which we have custom C-code blocks. 
• Unfortunately, the whole c1sus FE crashed when we tried rtcds restart c1pem.
• We tried a couple of more iterations, and attempted to monitor dmesg during the restart process to see if there were any clues as to why this wasn't working, but got nothing useful.

All models have been reverted to their state prior to this test, and everything on the CDS_OVERVIEW MEDM screen is green now.

Summary:

I spent this weekend doing a more careful investigation of the DRMI noise. I think I have some new information/insights. Attachment #1 is the noise budget (png attached because pdf takes forever to upload, probably some ImageMagick problem. The last attachment is a tarball of the PDF). Long elog, so here are the Highlights:

1. Coil de-whitening does result in small improvement in noise in the 60-200Hz band.
2. Above 200Hz, we seem to be limited by "Dark" noise. More on this below.
3. The coupling from SRCL->MICH is the other limiting noise in the 60-200Hz band now.

Sensing Matrix Measurement:

• I rotated the AS55 demod phase from -42 degrees to -82 degrees, the idea being to get more of the MICH error signal in AS55_Q.
• Consequently, the MICH servo gain has been lowered from -0.035 to -0.021. Settings have been updated in the snap file used by the locking script.  
• Seems to have worked.
• Attachment #2 is the measured sensing elements.
• One major source of uncertainty in these sensing element numbers is the actuator gains for PRM, SRM and BS. The coil driver electronics for the latter two have been modified recently, and for them, I am using numbers from this elog scaled by the expected factor as a result of removing the x3 gain in the de-whitening boards for SRM and BS.

MICH OLTF

• Measurement was done in lock using the usual IN1/IN2 method.
• Model made by loading the FOTON filters + assumed models for the BS pendulum and AA/AI filters in Matlab, and fitting to an overall gain + delay.
• Attachment #3 shows the agreement between measurement and model.
• The model was exported and used to invert in-loop signals to their out-of-loop counterparts in the noise budget.

DAC Noise

• I had claimed that turning on the coil de-whitening did not improve the MICH noise.
• This was not exactly true - I had only compared MICH noise with the BS de-whitening turned ON/OFF, while the ITM de-whitening was always on.
• Turns out that there is in fact a small improvement - see Attachment #4 (DTT crashes everytime I try to print a pdf, so png screenshot will have to do for now).
• I have also changed the way in which DAC noise is plotted in the Noise Budget code:
  • I used to directly convert the measured voltage noise (multiplied by appropriate scalar to account for quadrature sum of 4 coils each in 3 optics) to displacement noise using the sensing measurement cts/m values.
  • Now I convert the measured voltage noise first to current noise (knowing the series resistance), then to force noise (using the number 0.016 N/A per coil), then to displacement noise (assuming a mirror mas of 250g).
  • Quadrature sum is again taken for 4 coils on 3 optics.
• I've also added the option to plot the DAC noise with the de-whitening filter TF applied (taking care that the maximum of filtered DAC noise / coil driver electronics noise is used at each frequency).
• So the major source of uncertainty in the calculated DAC noise is the assumed actuator gain of 0.016 N/A.

The DAC noise is not limiting us anywhere when the coil de-whitening is switched on.

Dark Noise

I think this is the major find.

• The dark noise spectrum is measured with:
  • the PSL shutter closed
  • the AS55 I and Q analog whitening filters (and corresponding digital de-whitening filters) engaged, to mimic the operating conditions under which the in-lock error signal is acquired.
• Comparing the blue and black traces, it is clear that turning on the analog whitening is having some effect on the dark noise.
• However, the analog whitening filters should suppress the ADC noise by ~30dB @ 100Hz - so assuming 1uV/rtHz, this would be ~30nV/rtHz @100Hz.
• But the measured noise seems to be ~5x higher, with 4*10^-4 cts/rtHz translating to roughly 120nV/rtHz.
• The photodiode dark noise is only 15nV/rtHz according to the wiki. Where is this measured?

So I don't understand the measured Dark Noise level, and it is limiting us at frequencies > 200Hz. Some busted electronics in the input signal chain? Or can the LSC demod daughter board gain of ~5 explain the observed noise?

Shot noise

• The DC power on AS55 photodiode was measured to be ~13mW with the SRM misaligned.
• This corresponds to ~100cts peak amplitude on the ASDC channel (derived from AS55 photodiode).
• In the DRMI lock, the ASDC level is ~200cts.
• I used these numbers, and equation 2.17 in Tobin's thesis, to calculate this curve.

Edit 1730 9 Oct: I had missed out the factor of 5 gain in the demod board in calculating the shot noise curve. Attachment #7 shows the corrected shot noise level. Explicitly:

, where is to convert shot noise in W to displacement units.

AUX coupling

This is the other find.

• While chatting with Gabriele, he suggested measuring the SRCL->MICH and PRCL->MICH cross couplings.
• I injected a signal in SRCL servo EXC channel, and adjusted amplitude till coherence in MICH_IN1 was good.
• The actual TF measured was MICH_IN1 / SRCL_IN1 (so units of cts/ct).
• My multiplying the in-lock PRCL and SRCL IN1 signals by these coupling coefficients (assumed flat in frequency for now, note that measurement was only made between 100Hz and 1kHz), I get the trace labelled "AUX coupling" in Attachment #1 (this is the quadrature sum for SRCL and PRCL couplings).
• Also repeated for PRCL -> MICH coupling in the same way.
• Measurements of these TFs and coherence are shown in Attachment #5 (again png screenshot because of DTT).
• However, there is no significant coherence in MICH/SRCL or MICH/PRCL in this frequency range.

This seems to be limiting us from saturating the dark noise once the coil de-whitening is engaged. But lack of coherence means the mechanism is not re-injection of SRCL/PRCL sensing noise? Need to think about what this means / how we can mitigate it.

OL A2L coupling

• I didn't measure these
• These couplings would have changed because I modified the Oplev loop shapes to allow engaging of coil de-whitening filters.
• But anyways, their effect will only be below 100Hz because I made the roll-offs steeper.

Still to measure (but not likely to be limiting us anywhere in the current state):

• Laser intensity noise -> MICH coupling (using AOM).
• Laser frequency noise -> MICH coupling (using CM board IN2).
• Oscillator noise (amplitude + phase) -> MICH coupling (using AM/FM input of Marconi).

I've also made several changes to the NB code - will push to git once I finish cleaning stuff up, but it is now much faster to make these plots and see what's what.

My last characterization of the AS55 PD was on Feb 2013. ELOG 8100

There I said the dark noise at the PD output was 16nV/rtHz. I don't have the measurement of the Voltage noise at the output of the demod board.

Note that the PD can only be limited by shot noise when the DC current is larger then 4mA.

I measured the output voltage noise of the Q output of the AS55 Demod Board with the PSL shutter closed, using the SR785 (see Attachment #1). The measured noise is consistent with the expected number of ~120nV/rtHz around 100Hz. I had measured the gain of this board from RFPD input to Q output to be ~5.1: so if the PD dark noise is 16nV/rtHz, this would be amplified to ~80nV/rtHz. Still a discrepancy of ~50%. I didn't measure the noise with the PD input terminated. Added the noise of the demod board output with the RFPD input terminated. The level of ~100nV/rtHz seems consistent with the actual PD dark noise being ~80nV/rtHz, as their quadrature sum is around 130nV/rtHz. Need to dig up the schematics for the demod board + daughter board, and check against LISO, to see if this is consistent with what is expected.

Also - I think I was using the wrong value of the DC power on the AS55 photodiode for shot noise calculations - 13mW was for REFL55, not AS55. I did a crude measurement of the power by sticking the Ophir power meter (filter removed) in front of the AS55 PD with the Michelson flashing around, and noticed the maximum value registered was ~1.2mW. So in the DRMI lock, there would be ~2.4mW, which is 10x lower than the value I was assuming. I've made the correction in the NB code, for the next time the plot is generated. A more rigorous measurement would involve sticking the Ophir in front of the AS110 PD during a DRMI lock. The light from the AS port is split by a 50-50 BS to the AS55 and AS110 PDs (so measuring at AS110 is a reasonable proxy for power at AS55), and the AS110 signals are not used for triggering in the DRMI lock, so this is feasible.