Eurocrate key turning reboots today morning for c1psl and c1aux.c1auxex and c1auxey are also down but I didn't bother keying them for now. PSL FSS slow loop is now active again (its inactivity was what prompted me to check status of the slow machines).

Note that the EPCIS channels for PSL shutter are hosted on c1aux.But looks like the slow machine became unresponsive at some point during the weekend, so plotting the trend data for the PSL shutter channel would have you believe that the PSL shutter was open all the time. But the MC_REFL DC channel tells a different story - it suggests that the PSL shutter was closed at ~4AM on Sunday, presumably by the vacuum interlock system. I wonder:

1. How does the vacuum interlock close the PSL shutter? Is there a non-EPICS channel path? Because if the slow machine happens to be unresponsive when the interlock wants to close the PSL shutter via EPICS commands, it will be unable to. The fact that the PSL shutter did close suggests that there is indeed another path.
2. We should add some feature to the vacuum interlock (if it doesn't already exist) such that the PSL shutter isn't accidentally re-opened until any vacuum related issues are resolved. Steve was immediately able to identify that the problem was vacuum related, but I think I would have just re-opened the PSL shutter thinking that the issue was slow computer related.

 IFO pressure 1.2e-5 Torr at 9:30am

Atm. 1,  This was the vacuum condition  this morning.

               IFO P1  9.7 mTorr, V1 open,  V4 was in closed position , ~37 C warm Maglev at normal 560Hz rotation speed with foreline pressure 3.9 Torr because V4 closed 2 days ago when TP2 failed .....see Atm.3

               The error messege at TP2  controller was: fault overtemp.

I did the following to restored IFO pumping: stopped pumping of the annulose with TP3 and valves were configured so TP3 can be the forepump of the Maglev.

closed VM1 to protect the RGA,  close PSL shutter .....see Gautam  entry

aux fan on to cool down Maglev-TP1, room temp 20 C,

aux drypump turned on and opend to TP3 foreline to gain pumping speed,

closed PAN to isolate annulos pumping,

opened V7 to pump Maglev forline with TP3 running at 50Krpm, It took 10 minutes to reach P2  1mTorr from 3.9 Torr

aux drypump closed off at P2  1 mTorr, TP3 foreline pressure 362 mTorr.......see Atm.2

As we are running now:

IFO pressure 7e-6 Torr at Hornet cold cathode gauge at 15:50  We have no IFO CC1 logging now.  Annuloses are in 3-5 mTorr range are not pumped.

TP3 as foreline pump of TP1 at 50 Krpm, 0.24 A, 24 C, it's drypump forline pressure 324 mTorr

V4 valve cable is disconnected.

I need help with wiring up the logging of the Hornet cold cathode gauge.

Udit Kahndelwal received 40m specific basic safety traning on Friday, Oct. 27

Backed up all the wikis. Theyr'e in wiki_backups/*.tar.xz (because xz -9e gives better compression than gzip or bzip2)

Moved old user directories in the /users/OLD/

None of the 3 dd backups I made were bootable - at boot, selecting the drive put me into grub rescue mode, which seemed to suggest that the /boot partition did not exist on the backed up disk, despite the fact that I was able to mount this partition on a booted computer. Perhaps for the same reason, but maybe not.

After going through various StackOverflow posts / blogs / other googling, I decided to try cloning the drives using ddrescue instead of dd.

This seems to have worked for nodus - I was able to boot to console on the machine called rosalba which was lying around under my desk. I deliberately did not have this machine connected to the martian network during the boot process for fear of some issues because of having multiple "nodus"-es on the network, so it complained a bit about starting the elog and other network related issues, but seems like we have a plug-and-play version of the nodus root filesystem now.

chiara and fb1 rootfs backups (made using ddrescue) are still not bootable - I'm working on it.

Nov 6 2017: I am now able to boot the chiara backup as well - although mysteriously, I cannot boot it from the machine called rosalba, but can boot it from ottavia. Anyways, seems like we have usable backups of the rootfs of nodus and chiara now. FB1 is still a no-go, working on it.

Valve configuration: Vacuum normal

Note: Tp2 running at 75Krpm 0.25A 26C has a  load high pitch sound today. It's fore line pressure 78 mTorr. Room temp 20C

Lompoc 4.3M and 3.7M Avalon

Here are the demodulation phases and rotation matrices tuned for the network. For the matrices, I am assuming that the input is [I, Q] and the output is [I,Q].

POP22
phi = 153 degrees
[[-0.894, 0.447],
 [-0.447, -0.894]]

REFL11
phi = 93 degrees
[[-0.058, 0.998],
 [-0.998, -0.058]]

REFL55
phi = -90 degrees
[[0.000, -1.000],
 [1.000, 0.000]]

AS55
phi = 7 degrees
[[0.993, 0.122],
 [-0.122, 0.993]]

In order to try to isolate CPU6 for the c1dnn neural network reconstruction model, I set the CPUAffinity in /etc/systemd/system.conf to "0" for the front end machines.  This sets the cpu affinity for the init process, so that init and all child processes are run on CPU0.  Unfortunately, this does not affect the kernel threads.  So after reboot all user space processes where on CPU0, but the kernel threads were still spread around.  Will continue trying to isolate the kernel as well...

In any event, this amount of isolation was still good enough to get the c1dnn user space model running fairly stably.  It's been running for the last hour without issue.

I added the c1dnn channel and testpoint files to the daqd master file, and restarted daqd_dc on fb1, so now the c1dnn channels and test points are available through dataviewer etc.  We were then able to observe the reconstructed signals:

We'll need to set the phase rotation of the demodulated RF PD signals (REFL11, REFL55, AS55, POP22) to match them with what the NN expects...

[ Gautam , Steve ]

c1susaux & c1iscaux were rebooted manually.

[alex, gautam]

Alex is going to have an undergrad work on a calibration optimization project on the 40m RTCDS system. For this purpose, we wanted to setup a "Simulated DARM loop". Today, Alex and I set this up. I figured we can use the c1tst model for this purpose. We basically copied the topology from Figure 2 of the h(t) paper. Attached are screenshots of the MEDM screens of the system we setup, and the simulink block diagram - the main screen can be accessed from the "SIM PLANT" tab in the sitemp.

It remains to setup the appropriate filters in the filter banks, and an EPICS channel monitor for monitoring the single excitation testpoint in the model. We also did not set up any DQ channels for the time being, as it is not even clear to me what channels need to be DQ-ed.

Do not leave organic trash or food boxes in the 40m to attrack ants !

[steve, jamie, gautam]

The machine that now serves as out Frame Builder, FB1, was sitting on top of megatron. I decided that this wasn't ideal, and asked Steve to get some alternative mounting solution. Today, he procured some shelves to put FB1 on. Jamie suggested looking for the slider-rail that came with the machine, and using that instead, as it will allow us to slide FB1 out of the rack as we do megatron and the old FB. But as luck would have it, the distance between the rack vertical posts is 26 inches, but the rail is 27 inches. So we had to accept using the less ideal solution of putting FB1 on two shelves, with no sliding option. Photo to be uploaded shortly.

For this work, I had to shutdown FB1 for about 1 hour between 3pm and 4pm. It seems to have come back up fine now.

Gabriele's PRCL/MICH reconstruction neural network is now running on c1lsc.  Summary:

• front-end model is called c1dnn, and is running as an experimental user-space process
• c1dnn is getting most of it's needed inputs from existing SHMEM IPC outputs from c1lsc
• none of the output signals from the network are being sent anywhere yet (grounded)
• c1dnn has not been integrated in any way, into the DAQ etc.  it is being run manually by hand, and will be completely shut down after this test

Simple MEDM screen I made to monitor the input/output signals:

The RTS process seems to run fine, but there is quite a bit of jitter in the CPU_METER, at the 50% level:

It's not running over the limit, but it is jumping around more than I think it should be.  Will look into that...

cpuset for cpu isolation for user-space model

The c1dnn model is running on CPU6 on c1lsc.  CPU6 was isolated from the rest of the system using cpuset.  The "cset" utility was used to create a "system" CPU set that was assigned to CPU0, and the kernel was instructed to move all running processes to that set:

controls@c1lsc:~ 2$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y   343    0 /
controls@c1lsc:~ 0$ sudo cset set -c 0 -s system --cpu_exclusive
cset: --> created cpuset "system"
controls@c1lsc:~ 0$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y   342    1 /
       system          0 y       0 n     0    0 /system
controls@c1lsc:~ 0$ sudo cset proc --move -f root -t system -k
cset: moving all tasks from root to /system
cset: moving 292 userspace tasks to /system
cset: moving 0 kernel threads to: /system
cset: --> not moving 50 threads (not unbound, use --force)
[==================================================]%
cset: done
controls@c1lsc:~ 0$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y    50    1 /
       system          0 y       0 n   292    0 /system
controls@c1lsc:~ 0$ sudo cset proc --move -f root -t system -k --force
cset: moving all tasks from root to /system
cset: moving 50 kernel threads to: /system
[==================================================]%
cset: **> 29 tasks are not movable, impossible to move
cset: done
controls@c1lsc:~ 0$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y    29    1 /
       system          0 y       0 n   313    0 /system
controls@c1lsc:~ 0$

I then created a set for the RTS process ("rts-c1dnn") on CPU6, and executed the c1dnn model in that set:

controls@c1lsc:~ 0$ sudo cset set -c 6 -s rts-c1dnn --cpu_exclusive
cset: --> created cpuset "rts-c1dnn"
controls@c1lsc:~ 0$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y    24    2 /
    rts-c1dnn          6 y       0 n     0    0 /rts-c1dnn
       system          0 y       0 n   340    0 /system
controls@c1lsc:~ 0$ sudo cset proc -s rts-c1dnn --exec /opt/rtcds/caltech/c1/target/c1dnn/bin/c1dnn -- -m c1dnn
cset: --> last message, executed args into cpuset "/rts-c1dnn", new pid is: 27572
sysname = c1dnn
....

When done I just hit Ctrl-C.

I left the cpusets as they are, with all system processes in the "system" set.  This should not pose any problems since it's the identical configuration as would be if a normal kernel-level model was running in CPU6.

The c1dnn process and it's EPICS sequencer were shutdown after this test.

This happened again just now - it was roughly this time when this happened last night as well.

There was certainly an EPICS freeze of the kind we were used to seeing prior to replacing the martian wireless router sometime in late 2015 (or early 2016?). I was trying to run the dither alignment servos on the Y-arm at this time, and all the StripTool traces flatlined.

I took the opportunity to try accessing testpoints from the iscey ADCs - specifically C1:SUS-TRY_OUT, and it seemed to work just fine. However, I couldn't ssh into c1iscey.

Looking at the dmesg once I was able to ssh in eventually (~2 minutes deadtime tonight, I feel like it was longer yesterday but can't quantify), I see the following: not sure if there are any clues in here, or whether this is the correct log to check. But there are many instances of the nfs server related message in the log. Note that the system time-stamp corresponds to when this freeze happened.

Last night, I collected ~30mins of data for the vertex seismometer channels and the POP QPD PIT/YAW signals with the PRMI locked on carrier (angular FF OFF). The ITM Oplev loops weren't DC coupled, as they are in the full IFO locking sequence, but I feel like the angular FF filters can be improved - there are frequent sharp dives in the AS110 signal level which are correlated with large amplitude motion of the POP spot on the control room CCD monitor.

Repeating the frequency domain multicoherence analysis using BS_X and BS_Y seismometer channels as witnesses suggest that we can win significantly (see Attachment #1).

I've never really implemented feedforward filters - I was planning on using ericq's latest entry on this subject as a guide. From what I gather, the procedure is as follows:

1. Pre-filter the target (POP QPD PIT or YAW) and witness (BS_X, BS_Y) channels
   • Downsample the 2k target data and 256Hz witness data to 32 Hz (how to choose this?)
   • Detrend (linear?)
   • Apply elliptic low pass filter (previously, a 3rd order Elliptic Low pass with 3dB ripple, 40dB stopband attenuation, corner at 5Hz was used).
2. Filter the target signal (i.e. POP QPD PIT/YAW) by the inverse actuator TF.
   • This "actuator TF" is a measurement of how actuating on the angular DoFs of the PRM affects the POP QPD spot.
   • So by pre-filtering the target signal through the inverse actuator TF, we get a measure of how much the PRM angular motion is.
   • The reason we want to do this is to give the FIR filter that produces optic motion (output) given ground motion sensed by the seismometer (input) fewer poles/zeros to fit (?).
   • The actual actuator TF has to be measured using DTT, and fit - is there anything critical about this fitting? Seems like this should be just a simple pendulum transfer function so a pair of complex poles should be sufficient?
3. The actual Wiener filter is calculated by the function miso_firlev.m. There are many versions of this floating around from what I can gather.
   • This function requires 3 input parameters.
     • Order of filter to be fit
     • Witness channels (can be multiple)
     • Target channel (has to be single, hence the "miso" in the function name).
   • Today, at the meeting, we talked about weighting the cost function that the optimal Wiener filter calculator minimizes.
   • The canonical wiener filter minimizes the mean squared error between the output of the filter and the desired signal profile (which for this particular problem is the angular motion of the PRM, calculated by dividing the target signal by the actuator TF, knowing which we can cancel it out).
   • But as seen in Attachment #1, the main reduction in RMS comes below f=5Hz.
   • So can we weight the cost function more heavily at lower frequencies? From what I can find in previous calculations, it looks like this weighting happens in the pre-filtering stage, which is not the same thing as including the frequency dependent weighting in the calculation of the Weiner filter? The PSD and acf are F.T. pairs per the Wiener-Khinchin theorem so intuitively I would think that weighting in the frequency domain corresponds to weighting on the lags at which the acf is calculated, but I need to think about this.
   • What kind of low-pass filter do we use to prevent noise injection at higher frequencies? Does the optimal filter calculation automatically roll-off the filter response at high frequencies?
4. As I write this, seems like there is another level of optimization of "meta-parameters" possible in this whole process - e.g. what is the optimal order of filter to fit? what is the optimal pre-filtering of training data? Not sure how much we can gain from this though.

Some notes from Rana from some years ago: https://nodus.ligo.caltech.edu:8081/40m/11519

If anyone has pointers / other considerations I should take into account, please post here.

Summary:

The signal path for the ASDC signal is AS55 PD --> D990543 (interface board) --> D990694 (whitening board) --> D000076 (AA board) --> ADC Ch 31. Everything in this signal chain should be able to handle signals in the range +/- 10V, which should correspond to the full range of our +/-10V, 16bit ADCs. But the ASDC signal seems to saturate at ~2000 counts (i.e. turning up the analog whitening gain doesn't make the signal get any bigger than this). I investigated this a little more today.

Details:

• The ASDC signal is derived from the AS55 photodiode. According to the schematic, the Op27 that supplies this voltage is powered by +/- 15V, so the output should be able to swing between at least +/- 12V.
• The DC signal goes from the DB15 connector on the side of the PD to the LSC electronics rack, 1Y2, where it is interfaced with an LSC PD Interface Card, D990543. Again, per the schematic, the Op27 driving this voltage is powered by +/- 15V, and so the available output voltage swing should be greater than +/-12V.
• The D990543 output is to its backplane connector. There is an adaptor board hooked up to the backplane that makes these outputs available to a LEMO connector. A LEMO-SMA cable then pipes this output to a D990694.
  • I decided to test the functionality of this board.
  • Disconnected the SMA ASDC input signal (CH8 on the board).
  • Drove that channel with an SR function generator and gradually turned up the Vpp of the input signal (sine wave at 145Hz).
  • Monitored the ASDC channel on dataviewer while doing this.
  • Saw that the ASDC signal saturated at ~2000 counts. Turning up the signal amplitude did not have any effect.
• From the whitening board, the signal goes through an anti-aliasing module (D000076). The final stage LT1125s on these boards should also be supplied with +/-15V.

So the problem lies somewhere downstream of the D990694. There are other anomalous behaviours of this channel - e.g. engaging the analog whitening filters changes the DC offset of the signal. I am going to pull out this board to check it out.

Why does this matter? I want to calibrate the ASDC level (and eventually the other PD DC signals as well) into Watts. This is useful for IFO diagnostics, noise budgeting the shot noise level etc.

According to the AS55 schematic, the DC transimpedance is 66.7 ohms. I claim that the DC power on the AS55 photodiode during a DRMI (no arms) lock is ~1mW. The C30642 photodiode (InGaAs) responsivity is ~0.8 A/W. So I'd expect ~50mV to be the signal level into the ADC (assuming gain of all the other electronics in the signal chain at the start of this elog is unity). This corresponds to ~163 counts (since the ADC conversion factor is 2^16 counts over 20volts). The DC signal level I observed is ~200 counts. So things seem roughly consistent.

*Note: Despite my above statement, I don't think it is true that the AS110 PD has more light on it - the BS splitting the light between

AS55 and AS110 PDs is a 50-50 BS, and using the crude method of putting an Ophir power meter in front of both PDs and

monitoring the power while the Michelson was swinging around freely showed roughly the same maximum value.

The units were still off in my previous post. Here's the corrected, sanity-checked version:

I estimated the uncertainties based on a linear fit to the data I recorded with 75nW incident on the CCD and assumed a 5% uncertainty in that number. This is just an upper limit, to be safe. I had calibrated the power reading placing the Ophir power meter where the CCD would otherwise be and comparing it to the PD voltage of a picked off beam. In my previous figures the axes were mislabeled, so I reproduce them here:

Using the current camera position I recorded 50 exposures both with and without beam (XARM locked vs PSL shutter closed) and averaged the images to see how much the reading fluctuates. The exposure time was 10 ms, which left the maximum reported pixel value in all exposures below 3800 out of 4096. The gain setting was 100, which is what I used to calibrate the CCDs.

(*) I calculated the lens positions to focus at a plane 65cm from the front lens. We're pretty close to that, but I can't confirm the actual distance easily, so I assumed a 5cm error on the distance, which is where most of the error is coming from. This is also assuming uniform scatter.

(**) This is assuming 10W of circulating power

I tried moving the model to c1ioo, where there are plenty of free cores sitting idle, and the model seems runs fine.  I think the problem was just CPU contention on the c1lsc machine, where there were only two free cores and the kernel was using both for all the rest of the normal user space processes.

So there are two options:

• Use cpuset on c1lsc to tell the kernel to remove all other processes from CPU6 and save it just for the c1dnn model.  This should not have any impact on the running of c1lsc, since that's exactly what would be happening if we were running the model in kernel space (e.g. isolating the core for the front end model).  The auxilliary support user space processes (epics seq/ioc, awgtpman) should all run fine on CPU0, since that's what usually happens.  Linux is only using the additional core since it's there.  We don't have much experience with cpuset yet, though, so more offline testing will be required first.
• Run the model on c1ioo and ship the needed signals to/from c1lsc via PCIe dolphin.  This is potentially slightly more invasive of a change, and would put more work on the dolphin network, but it should be able to handle it.

I'm going to start testing cpuset offline to figure out exactly what would need to be done.

We don't really have to calibrate the lens, just the CCD, which we've done. It's more about knowing the true aperture size to know how much solid angle you're capturing to infer the total amount of scatter. For our custom lens tubes this is the ID of the retaining ring.

The Edmund Optics lens tube looks tempting, but itcomes at a price. Thorlabs sells lens tubes that offer a more flexibility than what we have right now, so I bought a few different ones, and also more 150mm 2" lenses. This will allow for more compact solutions and offer some in-situ focusing ability that doesn't require detaching the lens tube like now. Should be here in a couple of days, then we'll be able to enclose the GigE camera in the viewport can with a similar field of view we have now.

I also bought a collimation package for the AS port fiber stuff so we can move ahead with the ringdown measurements and also mode spectroscopy.

An mx_stream glitch would have interrupted data flowing from the front end to the DAQ, but it wouldn't have affected the heartbeat.  The heartbeat stop could mean either that the front end process froze, or the EPICS communication stopped.  The fact that everything came back fine after a couple of minutes indicates to me that the front end processes all kept running fine.  If they hadn't I'm sure the machines would have locked up.  The fact that you couldn't connect to the FE machine is also suspicious.

My best guess is that there was a network glitch on the martian network.  I don't know how to account for the fact that pings still worked, though.

I was looking at the ASDC channel on dataviewer, and toggling various settings like whitening gain. At some point, the signal just froze. So I quit dataviewer and tried restarting it, at which point it complained about not being able to connect to FB. This is when I brought up the CDS_OVERVIEW medm screen, and noticed the frozen 1pps indicator lights. There was certainly something going on with the end FEs, because I was able to ping the machine, but not ssh into it. Once the 1pps lights came back, I was able to ssh into c1iscex and c1iscey, no problems.

Could it be that some of the mx processes stalled, but the systemctl routine automatically restarted them after some time? 

So this wasn't just an EPICS freeze?  I don't see how this had anything to do with any of the work I did earlier today.  I didn't modify any of the running front ends, didn't touch either of the end station machines or the DAQ, and didn't modify the network in any way.  I didn't leave anything running.

If you couldn't access test points then it sounds like it was more than just EPICS.  It sounds like maybe the end machines somehow fell of the network momentarily.  Was there anything else going on at the time?

While working on the IFO tonight, I noticed that the blinky status lights on c1iscex and c1iscey were frozen (but those on the other 3 FEs seemed fine). But all other lights on the CDS overview screen were green I couldn't access testpoints from these machines, and the EPICS readbacks for models on these FEs (e.g. Oplev servo inputs outputs etc) were frozen at some fixed value. This lasted for a good 5 minutes at least. But the blinky lights started blinking again without me doing anything. Not sure what to make of this. I am also not sure how to diagnose this problem, as trending the slow EPICS records of the CPU execution cycle time (for example) doesn't show any irregularity.

[Koji, gautam]

We took a closer look at the AS55 demod board today. The procedure was to just be as thorough as possible, and check the behaviour of the circuit (both Transfer Function and Noise) stage by stage. Checking the transfer function was the key.

During this process, we found that the reason why the Q channels had lower noise than the I channels was because of the gain of the AD829 stage of the circuit was 0dB rather than 4dB (which is what it should be according to the component values used). Specifically, resistor R12, which is supposed to be 1.30kohm, was measured to be 1.03kohm. Replacing this resistor, the transfer functions (see Attachment #1) and noise levels (see Attachment #2) match the expectations from LISO. Some notes:

1. The daughter board essentially consists of 2 stages
   • OP27 stage, which has a design gain of 16dB ((=316ohm/50ohm) (flat at frequencies <100kHz).
   • AD829 stage, which has a design gain of 4dB (=1.3kohm/768ohm), and is a 2nd order Butterworth LPF with corner @ 1MHz.
   • So the overall gain of the daughter board is 20dB (i.e. x10) at audio frequencies.
2. The output noise of D040179 is expected to be ~35nV/rtHz at 100Hz, and the measurement (made with inputs soldered together) is consistent with this value.
3. The measured voltage noise at the input to D040179 (i.e. the output of the minicircuits mixer + SCLF-5 LPF) is ~9nV/rtHz.
4. The output voltage noise of the demod board with RFPD input terminated then is expected to be the quadrature sum of the noise due to the D040179 electronics (i.e. 40nV/rtHz) and the input noise to the D040179 (i.e. 9nV/rtHz) multiplied by the gain of the daughter board (i.e. x10) == .
5. To calculate the "dark noise" contribution of AS55 to MICH displacement noise, we have to further add the photodiode dark noise contribution: this gets us up to . This is consistent with the measurement (see Attachment #2).

6. Assming the whitened ADC noise level is much below this (should only be ~10nV/rtHz), and given the measured sensing element of 6.2e8 V/m, this means that the dark noise sets a maximum achievable sensitivity of 2e-16m/rtHz.

To figure out what (if anything) is to be done next, we need to first figure out what is the goal. In the end, we care about DARM and not MICH. The optical gain for the former is ~300x the latter, so the dark noise contribution gets scaled by this factor (giving us a number of 7e-19 m/rtHz). There are certainly many noises above that level which have to be handled first. Indeed, looking at the DARM spectrum from DRFPMI lock back in March 2016, it looks like the current 1f DRMI (with coils de-whitened) Michelson sensitivity is within a factor of 2 of DARM in the full lock (albeit with vertex DoFs on 3f signals, and no coil de-whitening). Koji pointed out that we need to consider the photodiode resonant circuit itself too.

TODO: Upload all this onto the DCC

I've been preparing for testing Gabriele's deep neural network MICH/PRCL reconstruction.  No changes to the front end have been made yet, this is all just prep/testing work.

Background:

We have been unable to get Gabriele's nn.c code running in kernel space for reasons unknown (see tests described in previous post).  However, Rolf recently added functionality to the RCG that allows front end models to be run in user space, without needing to be loaded into the kernel.  Surprisingly, this seems to work very well, and is much more stable for the overall system (starting/stopping the user space models will not ever crash the front end machine).  The nn.c code has been running fine on a test machine in this configuration.  The RCG version that supports user space models is not that much newer than what the 40m is running now, so we should be able to run user space models on the existing system without upgrading anything at the 40m.  Again, I've tested this on a test machine and it seems to work fine.

The new RCG with user space support compiles and installs both kernel and user-space versions of the model.

Work done:

• Create 'c1dnn' model for the nn.c code.  This will run on the c1lsc front end machine (on core 6 which is currently empty), and will communicate with the c1lsc model via SHMEM IPC.  It lives at:
  • /opt/rtcds/userapps/release/isc/c1/models/c1dnn.mdl
• Got latest copy of nn.c code from Gabriele's git, and put it at:
  • /opt/rtcds/userapps/release/isc/c1/src/nn/
• Checked out the latest version of the RCG (currently SVN trunk r4532):
  • /opt/rtcds/rtscore/test/nn-test
• Set up the appropriate build area:
  • /opt/rtcds/caltech/c1/rtbuild/test/nn-test
• Built the model in the new nn-test build directory ("make c1dnn")
• Installed the model from the nn-test build dir ("make install-c1dnn")

Test:

I tried a manual test of the new user space model.  Since this is a user space process running it should have no affect on the rest of the front end system (which it didn't):

• Manually started the c1dnn EPICS IOC:

  • $ (cd /opt/rtcds/caltech/c1/target/c1dnn/c1dnnepics && ./startupC1)

• Tried running the model user-space process directly:

  • $ taskset -c 6 /opt/rtcds/caltech/c1/target/c1dnn/bin/c1dnn -m  c1dnn

Unfortunately, the process died with an "ADC TIMEOUT" error.  I'm investigating why.

Once we confirm the model runs, we'll add the appropriate SHMEM IPC connections to connect it to the c1lsc model.

Koji suggested looking at the output of the AS55 demod board on a fast oscilloscope to look for differences in the two channel outputs (if there is some high-frequency oscillations, for example, we could miss this information in the SR785 spectra). Besides, I was only looking at spectra out to a few kHz on the SR785. I grabbed this data with a 300MHz BW Tektronix oscilloscope (battery mode) today. Input impedance of both channels were set to 1Mohm, and the measurement was made with the RFPD input terminated, output of the daughter board is what is measured. The vertical scaling of the channels was set to the minimum allowed, 1mV/div.

Attachment #1 shows that there is indeed a visible difference between the two channels - the (noisier) I channel has a much larger DC offset of ~5mV compared to the Q channel (I tried switching channels on the O'scope and the larger DC offset remained on the I channel, so seems real). There is also some kind of oscillation going on in the I channel, although the frequency is pretty low, with the peaks spaced ~50us apart. Indeed, in the ASD of the acquired data, the excess power in the I channel at 20kHz and higher harmonics are evident (see Attachment #2). Anyway all of this points to something being anomalous on the daughter board I channel signal path - I will pull it out and monitor the outputs at various points along the signal path with the fast scope to see if I can narrow down what's going on where.

Wall StripTool traces showed that IMC has not been locked for at least 8 hours when I came in this morning. Going to the IMC autolocker log, it looks like the last timestamp was at ~6pm yesterday. Megatron was responding to ping, but I couldn't ssh into it. So I went over to the machine and did a hard-reboot via front panel power switch. The computer took ~10mins to come back online and respond to ping. Once it did, I was able to ssh into it. However, trying the usual commands to restart the IMC autolocker and FSS Slow loops didn't work. Specifically, monitoring the logfile with tail -f Autolocker.log, I would see that the autolocker seemed to get stuck after starting the "blinky" script. Trying to restart the process using sudo initctl restart MCautolocker, init would print to shell that the restart had worked, and reported the PID, but the logfile wouldn't update "live" as it should when tail is used with the -f option. All very strange .

Anyways, as a last resort, I kill -9'ed the PID for the init instance, and init automatically restarted the Autolocker - this did the trick, IMC is locked now and logfile seems to be getting updated normally.

I also cleared a bunch of matlab crash dump files in the home directory.

Attachment #1 - Measured / modelled noises for AS55 demod board. I've plotted quadrature sum of the LISO trace with the SR785 noise floor with input terminated to ground via 50ohm. Note that these measurements were made after all the changes in the marked up schematic in the previous elog were implemented.

Both channels should be identical - I don't understand why the I channels are noisier than their Q counterparts. This is almost certainly a problem on the daughter board, as the orange traces are pretty much identical for both channels.

The dark red curves were measured by shorting the inputs to D040179 to ground via 50ohms using some Pomona minigrabbers - I wanted to avoid ripping the daughter board out, but this probably explains the excess noise compared to the green trace at low frequencies. All other measurements were made with the board installed in the LSC rack eurocrate, with the LO input driven at the nominal level (I didn't measure this yesterday but a measurement from ~6months ago says that this level is 1.5dBm).

Steve reported problems getting the X arm locked. Alignment sliders were inaccessible. Eurocrate key turning reboots for c1susaux, c1auxex,c1auxey, c1iscaux and c1aux. Usual precautions were taken for ITMX.

This is becoming a once-a-week thing .

Here is the marked up schematic with the board as it is stuffed. Annoyingly, there is a capacitor (C1) which according to the schematic is supposed to be open, but is stuffed in our board. I can't find any elog about this, and its a pain to measure the value of this capacitance. I will upload all of this + LISO + noise model/measurements to a 40m AS55 daughter board DCC page.

 Telescope front lens to wall distance 25 cm,  GigE camera lenght 6 cm and cat6 cable 2cm

 Atm3,   Existing short camera  can has 16cm  lenght to lexan guard on viewport. Available 2" od periscope tube lenght is 8cm. The one in use 16 cm long.

             Note: we can fabricate a lite cover with tube that would accomodate longer telescope.

             Can we calibrate the AR coated M5018-SW and compare it's performance agains the 2" periscope

             Look at the Edmond Optics 3" od camera lens with AR

This lower priced   1" apeture Navitar lens  can be an option too.

 Atm1,   Now I can see dust. This is much better. The focus is not right yet.

Atm2,   Chamber viewport wiped and image refocused. Actually I was focusing on the dust.

I worked on the daughter board a little more in the evening. I have somehow managed to make the dark noise ~25% worse [Attachment #1].

• Earlier in the day, I had switched out both on-board AD797s for OP27. The latter has ~3x the input voltage noise, and LISO modeling suggests that this is the dominant contribution to the output voltage noise.
• There are some differences in the actual components with which the board is stuffed, and the schematic. 
• After updating the LISO model, I expect to get an output voltage noise of ~50nV/rtHz. But I measured ~2x this value (measured with LO input of demod board driven, RFPD input terminated).
• While I had the board out, I replaced most of the installed thick-film resistors with thin film ones. For good measure, I also changed the AD829s.

After making all these changes, I re-installed the card in the eurocrate and repeated the measurement. The Q channel noise was close to the expected value (~50nV/rtHz), but the I channel is twice as noisy. I will continue this investigation tomorrow.

I calculated a better lens solution for the ETMX side view with the simple python script that's attached. The camera is still not as close to the viewport as we would like, and now the front lens is almost all the up to the end of the tube. With a little more playing around there maybe a better way, especially if we expand the repertoire of focal lengths. Using Steve's wonderful camera fixture I put the beam spot in focus. I turned the camera sideways for better use of the field of view, and now the beam spot actually fills the center area of the beam, to the point where we probably don't want more magnification or else we start losing the tails of the Gaussian.

We'll take a serious of images tomorrow, and will have an estimate of the scatter loss by the end of tomorrow.

I tried replacing the AD797s on the daughter board with OP27s, and saw no significant improvement in the electronics noise of the demod board. Note that according to LISO, in this configuration, the voltage noise of the Op27 is expected to dominate the total noise of the daughter board. Measurement condition was that the RFPD input was terminated, but the LO input was still being driven (SR785 input range is -50dBVpk for all traces, and the input ranging was set to "UpOnly"). Need to do a more systematic investigation to figure out where this excess noise is coming from. I will upload photos of the board later.

these are not the SR785 settings that you're looking for

To get low noise measurements on the SR785, you have to have the input range set to -50 dB, not +20 dB. Its not within the powers of commercial electronics ADCs to give you a 10 nV noise floor with +10 V input signals. The SR560 has an input referred noise of 5 nV/rHz, so the output noise should be 5e-9 x 500 = 2.5 uV/rHz. Your picture shows it giving 1 uV RMS, so you also need to use the PSD units.

I keep adding traces to this plot, here is the most complete one I have now. Looks like the input noise to the D040179 (measured at "Q out" SMA jack of D990511 with RFPD input terminated) is ~10nV/rtHz. This supports the hypothesis that something is wonky on the daughter board, because the purple trace should only be the quad sum of the orange and green traces. I will pull it out and have a look.

Some other follow-ups on the questions raised at the meeting:

1. Doesn't look like I've implemented thin film resistors on the input of the coil driver boards. De-whitening boards have the critical signal path resistors (judged as the ones with largest contribution as per LISO model) changed to thin film. Pictures are here.
2. I think I didn't make a full elog of my demod board efficiency investigations, but from my notes and Attachment #4 of elog 12972, I calculated the gain in the signal path as the ratio of Vpp_out / Vpp_in.

Gautam and Steve,

All 3 show the same noise level ~80 nV / rt Hz at 1 kHz as shown. Batteries ordered to be replaced in the top 2

We'll do more measurement to see how can we get to 4 nV / rt Hz  specification level.

how about calibrate the DC channels so that you can just get the acutal power levels from the trend data?

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.

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.

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.

There are no more double sided tape on this table.

[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.

Looks to have worked this time around.

I was able to mount all the partitions on the cloned disk. Will now try booting from this disk on the spare machine I am testing in the office area now. That'd be a "real" test of if this backup is useful in the event of a disk failure.

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

[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. 

The 4TB HGST drives have arrived. I've started the FB1 dd backup process. Should take a day or so.

MC Autolocker was umnhappy because c1iool0 was unresponsive and hence it couldn't write to the "C1:IOO-MC_AUTOLOCK_BEAT" channel. I keyed the crate and IMC locked almost immediately. I'm moving this channel into the RTCDS model as we did for the IFO_STATE EPICS channel so that the autolocker isn't dependant on c1iool0 (which was the whole point of migrating the IFO-STATE variable anyways). I also commented out all of these channels in /cvs/cds/caltech/target/c1iool0/autolocker.db so that there aren't duplicate channels.

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?