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

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

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

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

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

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

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

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

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

Progress so far:

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

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

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

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

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

[rana,gautam]

Summary:

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

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

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

Next steps:

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

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

To get our rsync back to LDAS back up, I followed instructions from Dan Kozak:

1. mounted /frames from fb1: I modified /etc/fstab
2. modified /etc/rsyncd.conf to allow access from LDAS
3. restarted rsync as daemon: 'sudo /usr/bin/rsync --daemon --config=/etc/rsyncd.conf'

Next need to figure out what the SL7 protocol is for running this as a daemon after boot - some kind of init.d thing probably

[koji, gautam]

We noticed quite a strong burning smell in the office area and control room ~20mins ago. We did a round of the bake lab, 40m VEA and the perimeter of the CES building, and saw nothing burning. But the smell persists inside the office area/control room (although it may be getting less noticeable). There is a whining noise coming from the fan belt on top of the office area. Anyways, since nothing seems to be burning down, we are not investigating further.

Steve [ 10am 5-31 ] we should always check partical count in IFO room

Service requested 

The AUX laser is down to 5.4 mW output power

What's worse, because we wanted those fast switching times by the AOM for ringdowns, I made the beam really small, which

1. came with a severe tradeoff against conversion efficiency. I tried to squeeze the last out of it today, but there's only about 1.3 mW of diffracted light in the first order that reaches the fiber, with higher diffraction orders already visible.
2. produced a very elliptical mode which was difficult to match into the fiber. Gautam and I measured 600 uW coming out of the fiber on the AS table. This per se is enough for the SRC spectroscopy demonstration, but with the current setup of the drive electronics there's no amplitude modulation of the deflected beam.

When going though the labs with Koji last week I discovered a stash of modulators in the Crackle lab. Among them there's an 80 MHz AOM with compact driver that had a modulation bandwidth of 30MHz. The fall time with this one should be around 100ns, and since the arm cavities have linewidths of ~10kHz their ringdown times are a few microseconds, so that would be sufficient. I suggest we swap this or a similar one in for the current one, make the beam larger, and redo the fiber modematching. That way we may get ~3mW onto the AS table.

I think I want to use AS110 for the ringdowns, so in the next couple days I'll look into its noise to get a better idea about what power we need for the arm ringdowns.

Seems like as a result of my recent poking around at 1X6, MC3 is more glitchy than usual (I've noticed that the IMC lock duty cycle seems degraded since Tuesday). I'll try the usual cable squishing voodo.

gautam 8.15pm: Glitches persisted despite my usual cable squishing. I've left PSL shutter closed and MC watchdog shutdown to see if the glitches persist. I'll restore the MC a little later in the eve.

Jon informed me that there are some EPICS channels that JoeB's camera server code looks for that don't exist. I thought Jigyasa and I had added everything last year but turned out not to be the case. I followed my instructions from here, did the trick. While cleaning up, I also re-named the "*MC1" channels to "*ETMX", since that's where the camera now resides. New channels are:

C1: CAM-ETMX_ARCHIVE_INTERVAL (Archival interval in minutes)
C1: CAM-ETMX_ARCHIVE_RESET (Reset Archival interval in minutes)

C1: CAM-ETMX_CONFIG_FILE (Config file)
 

I have attached the result of running the PID script on the seismometer with the can on. The daily fluctuations are no more than 0.07 degrees off from the setpoint of 39 degrees. Not really sure what happened in the past day to cause the strange behavior. It seems to have returned back to normal today.

megatron had full of zombie medm processes due to some of the screenshot scripts.

I also found that apache2 is running on megatron without any configuration. I just disable it by

sudo update-rc.d apache2 disable

The model of our martian wifi router (NETGEAR R6400) was found in the FBI router list to be rebooted asociated with the malware "VPNFilter" issue.

I checked the attached devices and found bunch of (legit) devices blocked to access the wifi router. This is not an immediate problem as most of the packets do not go through the wifi router. But potentially a problem in some cases like Wifi enables GPIB adapters. So I marked them to be "allowed".

In this opprtunity, I have updated the firmware of the wifi router and this naturally involved rebooting of the device.

Summary:

I wanted to recover the DRMI locking. Among other things, Jon mentioned that his mode spectroscopy can be done in the DRMI config. But I was foiled last night by a rogue waveplate in the AS beampath, and today evening, I noticed the resurfacing of this problem. Clearly, this is indicative of some issue in the analog whitening electronics, as the DC light level on the AS55 PD is consistent with previous measurements. Moreover, last time, the problem "fixed itself" so I don't know what exactly the problem was in the first place. I'll try doing the same test in the linked elog tomorrow. As a quick test, I cycled through the whitening gains (0-45dB) to see if it was some stuck ADC register, but that didn't fix the problem.

The problem seems to be with REFL55 only - I am able to lock the PRMI with carrier resonant without any issues, and the error signal levels are consistent with what I remember them being while the PRMI is swinging around. AS55 lives on the same whitening board and doesn't seem to suffer from the same probelms.

Decided to do the check tonight, but as Attachment #1 shows, no real red flags from the whitening gain side.

As it happened last time, the problem apparently fixed itself - somehow the act of me disconnecting the cables and reconnecting them seems to solve the problem, need to think about this.

Anyway, DRMI was locked a few times tonight. I got in a good long stretch where I ran some sensing lines and collected some data, analysis tomorrow. I am going to center the vertex oplevs as an alignment reference for now. A major source of lockloss seems to be angular instability - see for example this video grab of POP:

Could be due to noise injection from the noisy PRM Oplev HeNe, or just TT mirror angular motion (I couldn't get the PRC angular FF going tonight).

Aim: To synchronize data from the captured video and the signal applied to ETMX

In order to correlate the intensity fluctuations of the scattered light with the motion of the test mass, we are planning to use the technique of neural network. For this, we need a synchronised video of scattered light with the signal applied to the test mass. Gautam helped me capture 60sec video of scattering of infrared laser light after ETMX was dithered in PITCH at ~0.2Hz..

I developed a python program to capture the video and convert it into a time series of the sum of pixel values in each frame using OpenCV to see the variation. Initially we had tried the same with green laser light and signal of approximately 11.12Hz. But in order to see the variation clearly, we repeated with a lower frequency signal after locking IR laser today. I have attached the plots that we got below. The first graph gives the intensity fluctuations from the video. The third and fourth graphs are that of transmitted light and the signal applied to ETMX to shake it. Since the video captured using the camera was very noisy and intensity fluctuations in the scattered light had twice the frequency of the signal applied, we captured a video after turning off the laser. The second plot gives the background noise probably from the camera. Since camera noise is very high, it may not be possible to train this data set in neural network.

Since the videos captured consume a lot of memory I haven't uploaded it here. I have uploaded the python code 'sync_plots.py' in github (https://github.com/CaltechExperimentalGravity/GigEcamera/tree/master/Pooja%20Sekhar/PythonCode).

I brought the NPRO from the Crackle experiment over to the 40m Lab and set it up on the PSL table to replace the slowly dying AUX laser. I also brought along a Faraday isolator, broadband EOM, and an ISOMET AOM with driver electronics from the optics storage in the Crackle Lab.

This laser is a much newer model, made in 2008, and still has all its mojo, but we should probably keep up the practice of turning it off when it's not going to be used for a while. I measured 320 mW leaving the laser, and 299mW of that going through the Faraday isolator, whose Brewster-angle polarizer I had to clean because they were a little dusty. While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted. This is a completely different failure mode from what we've seen with the other NPROs that we can hopefully get repaired at some point, particularly because the laser is newer, but for now it's installed on the PSL table. This likely means that the noise eater isn't working on this unit either, for different reasons, but at least we have plenty of optical power.

The setup is very similar to before, with the addition of a Faraday isolator and a broadband EOM, in case we decide to get more bandwidth in the PLL. I changed the Crystal Technologies 3200-113 200 MHz AOM for an ISOMET 80 MHz AOM with RF driver from the Crackle lab's optics storage and sized the AUX beam to a diameter of 200 micron. I couldn't locate an appropriate heat sink for the driver, which is still in factory condiction, but since the PSL AOM also runs on 80MHz I used that one instead. The two AOMs saturate at different RF powers, so care must be taken to not drive the AUX AOM too high. At 600 mV input to the driver the deflection into the first order was maximal at 73 % of the input power, with the second order beam and the first order on the other side cleary visible.

In order to speed things up I didn't spend too much time on mode-matching, but the advantage of the fiber setup is that we can always improve later if need be without affecting things downstream. I coupled the first order beam into the fiber to the AS table with 58% efficiency, and restored the beat with the PSL laser on the NewFocus 1611. The contrast there is only about 20%, netting a -20 dBm beat note. This is only a marginal improvement from before, so the PLL will work as usual, but if we get the visibility up a little in the future we won't need to amplify the PD signal for the PLL anymore.

Some more things I wanted to do but didn't get to today are

• Measure intensity noise of aux laser
• Measure rise and fall times of new AOM
• Get PLL back up and running
• Place 90/10 beamsplitter in AS path and couple IFO output into fiber (= couple fiber output into IFO)

I'll resume this work tomorrow. I turned the aux laser and the AOM driver input off. For the PSL beat the AOM drive is not needed, and the power in the optical fiber should not exceed 100 mW, so the offset voltage to the AOM RF driver has to remain below 300 mV.

> While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted.

NPRO internal power monitor often shows smaller value than the actual due to a broken PD or misalignment. I don't think we need to fix it.

STEVE: Aux Lightwave M126-1064-200, sn259 [July 2009] 1.76A, ADJ 9,  9mW on it's display should not mislead you. It's output  320mW

We have the appropriate heatsink - I'd like to minimize interference with the main beam wherever possible.

If damage to the fiber is a concern, I think it's better to use a PBS + waveplate to attenuate the power going into the fiber. When the AOM switching is hooked up to CDS, it's easy to imagine a wrong button being pressed or a wrong value being typed in.

It would probably also be good to have a pickoff monitor for the NPRO DC power so that we can confirm its health (in the short run, we can hijack a PSL Acromag channel for this purpose, as we now do for FSS_RMTEMP). I don't know that we need an EOM for the PLL, as in order to get that going, we probably need some fast electronics for the EOM path, like an FSS box. 

STEVE: I ordered the right heatsink for the acousto after Koji pointed out that the vertical fins are 20% more efficient. Why? Because hot air rises. It will be here in 3-4 days.

I spent a day trying to modify Joe B.'s LLO camera client-server code without ultimate success. His codes now runs without throwing any errors, but something inside the black-box handoff of his camera source code to gstreamer appears to be SILENTLY FAILING. Gautam suggested a call with Joe B., which I think is worth a try.

In the meantime, I've impemented a simple Python video feed streamer which does work, and which students can use as a base framework to implement more complicated things (e.g., stream multiple feeds in one window, save a video stream movie or animation).

It uses the same PyPylon API to interface with the GigE cameras as does Joe's code. However, it uses matplotlib instead of gstreamer to render the imaging. The matplotlib code is optimized for maximum refresh rate and I observed it to achieve ~5 Hz for a single video feed. However, this demo code does not set any custom cameras settings (it just initializes a camera with its defaults), so it's quite possible that the refresh rate is actually limited by, e.g., the camera exposure time.

Location of the code (on the shared network drive):

/opt/rtcds/caltech/c1/scripts/GigE/demo_with_mpl/stream_camera_to_mpl.py

This demo initializes a single GigE camera with its default settings and continuously streams its video feed in a pop-up window. It runs continuously until the window is closed. I installed PyPylon from source on the SL7 machine (rossa) and have only tested it on that machine. I believe it should work on all our versions of Linux, but if not, run the camera software on rossa for now.

Usage:

From within the above directory, the code is executed as 

$python stream_camera_to_mpl.py [Camera IP address]

with a single argument specifying the IP address of the desired camera. At the time I tested, there was only one GigE camera on our network, at 192.168.113.152.

The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.

[johannes, gautam]

1. Johannes aligned the single bounce off the ITM into the AUX fiber on the AS table, and also the AUX beam into the fiber on the PSL table.
   • Mode matching isn't spectaular anywhere in this chain.
   • But we have 2.6mW of light going into the SRM with the AOM deflection into the 1st order beam (which is what we send into the IFO) maximum.
2. We set up some remote capabilities for the PLL and Marconi frequency (=PLL setpoint) control.
3. Motivation was to try and lock DRMI, and look for some resonance of the AUX beam in the SRC.
   • We soon realized this was a way too lofty goal.
   • So we decided to try the simpler system of PRMI locked on carrier.
   • We were successfully able to sweep the Marconi setpoint in up to 20kHz steps (although we can only move the setpoint in one direction, not sure I know why now).
   • Then we decided to look for resonances of the AUX beam in the arm cavity.
   • Still no cigar
     
4. Plus points:
   • PLL can be reliably locked remotely.
   • Marconi freq. can be swept deterministically remotely.
5. Tomorrow:
   • Fix polarization issues. There is some low freq drift (~5min period) of the power incident on the fiber on the PSL table which we don't understand.
   • Verify MM into IFO and also into fiber at PSL table.
   • Do mode spectroscopy.

I was wondering why the PMC modulation sidebands are showing up on the control room analyzer with ~6dB difference in amplitude. Then I realized that it is reasonable for the cabling to have 6dB higher loss at 80 MHz compared to 20 MHz.

Aha! Video is back!

I think it would be good to add a flag whereby the video can be saved to disk in some uncompressed video format (ogg, avi, ?) instead of displayed to a matplotlib window. We could then use the default to just display video, but use the save-to-disk flag to grab a few minutes of video for image processing.

[steve, gautam]

We added the following channels to C0EDCU.ini and restarted the daqd processes. Channels seem to have been added successfully, we will check trend writing later today. Motivation is to have a long term record of annulus pressure (even though we are not currently pumping on the annulus).

C1:Vac-PASE_status

C1:Vac-PASV_status

C1:Vac-PABS_status

C1:Vac-PAEV_status

C1:Vac-PAEE_status

plot next day

For some time now, I've been puzzled by the unreliability of the ASS_X dither alignment servo. Leaving the servo on, TRX often begins to decay to a lower value, and even after freezing the dither at the maximum TRX values, I can manually align the mirrors to increase TRX. We have suspected some kind of clipping in the TRX path that is responsible for this behaviour. Today I decided to investigate this a bit further. To have the arm locked and to inspect the beam, we have to change the locking trigger - TRX is what is normally used, but I misaligned the Y arm completely, and used AS110 as a trigger instead. There is some strangeness in the triggering topology, but this deserves a separate elog.

Once the arm was locked (and relocks using the AS110 trigger in the event of an unlock), I was able to trace the beampath on the EX table with an IR card. The TRX beam is rather large and weak, so it is hard to see, but as best as I can tell, the only real danger of clipping (or perhaps the beam is already clipped) is on the final steering mirror before the beam hits the (Thorlabs) PD. Steve/Pooja are working on getting a photo of this, and will upload it here shortly. Options to mitigate this:

1. Use the harmonic separator to steer the beam lower, and center it on the 1" steering mirror. However, this could possibly lead to clipping on some of the upstream lenses.
2. Raise the height of the 1" steering mirror by 0.25". However, this would require a custom 3/4" dia post height or some shims, which I am not sure is in line with our optomechanic mounting practises.
3. Use a 2" mirror instead of a 1" mirror.

The EX QPD has stopped working since the Acromag install. If it were working, we wouldn't have to rely on the alternate triggering with AS110 and instead just use the QPD as TRX, while we debug the Thorlabs PD path.

I though that the "C1LSC_TRIG_MTRX" MEDM screen completely controls the triggring of LSC signals. But today while trying to trigger the X-arm locking servo on AS110 instead of TRX, I found some strange behaviour. Summary of important points:

1. Even though the servo was supposed to be triggered on AS110, the act of me blocking the beam on the EX table destroyed the lock. I verified the correlation between me blocking the beam and the lock being destroyed by repeating the blocking at least 10 times at different locations along the beam path (to make sure I wasn't accidentally clipping the Oplev beam for example).
2. Investigating further, I found that me turning off the TRX signal digitally also deterministically led to the X arm lock being lost. To be clear, the TRX DC element in the trigger matrix was 0.
3. Confirmed that TRX wasn't involved in any way in the locking servo (I was checking for normalization of the PDH error signal by the DC transmission value, but this is not done). To do this, I locked the arm, and then turned all elements corresponding to TRX in the PowNorm matrix to 0. Then I disabled the locking servo and re-enabled it, and the lock was readily re-acquired readily.

All very strange, not sure what's going on here. The simulink model diagram also didn't give me any clues. Need's further investigation.

Got this 1U box from the Y arm that we could potentially use (attachment 1). It doesn't have handles on the front but I guess we could attach them if necessary. Attachment 2 is a switch that could be used instead of a light up switch, but now we need to add LEDs on the front panel that indicate that the switch is functional. Attachment 3 is a terminal block that we can use to attach the 16 gage wire to since it is thick and attaching it directly to the board would be difficult. If this is alright to use then I'll change up my designs for the front panel and PCB to accomodate these parts.

FSS slow wasn't running so PSL PZT voltage was swinging around a lot. Reason was that was c1psl unresponsive. I keyed the crate, now it's okay. Now ITMX is stuck - Johannes just told be about an un-elogged c1susaux reboot. Seems that ITMX got stuck at ~4:30pm yesterday PT. After some shaking, the optic was loosened. Please follow the procedure in future and if you do a reboot, please elog it and verify that the optic didn't get stuck.

I think this table will help us to fix the scanning range of the Marconi frequency. This will also help in predicting the position of the resonance peak corresponding to the injected frequency.

f_diff = f_m ±80 MHz ;                     f_diff = N*FSR_y ;              FSR_y = 3.893 MHz.

I opted for the quickest fix - I raised the height of the offending steering mirror using a 0.25" shim. In the long term, we can get a taller post machined. After raising the mirror height, I then checked the DC centering of the spot on the DC PD using a scope.

Looking at the performance of the X arm ASS, I no longer see the strange oscillatory behaviour I described in my previous post . Moreover, the TRX level was ~1 before be raising the steering mirror - but it is now ~1.2. So we were certainly losing some power.

Just to inform, I'm working in optimus to develop python code to train the neural network since it requires a lot of memory.

Local backup on chiara seems not working since Nov 19, 2017.
/opt/rtcds/caltech/c1/scripts/backup/localbackup.log

2017-11-18 07:00:01,504 INFO       Updating backup image of /cvs/cds
2017-11-18 07:03:00,113 INFO       Backup rsync job ran successfully, transferred 1954 files.
2017-11-19 07:00:02,564 INFO       Updating backup image of /cvs/cds
2017-11-19 07:00:02,592 ERROR      External drive not mounted!!!

I worked a bit on the PSL table today

It isn't clear to me in the drawing where the Agilent is during this measurement. Over 40m of cabling, the loss of signal can be a few dB, and considering we don't have a whole lot of signal in the first place, it may be better to send the stronger RF signal (i.e. Marconi pickoff) over the long cable rather than the weak beat signal from the Transmission photodiode. 

Among the things that we hadn't taken care of yesterday before beginning to look for transmission signals were the polarization of the AUX beam on the AS table and optimizing the PLL feedback. The AUX beam is s-polarized on the PSL table (choice due to availablility of mirrors), and I added a half waveplate in front of the fiber to match it's axes. I placed another half-waveplate at the fiber output and send the reflection port of a PBS cube onto a PDA1CS photodetector. By alternatingly turning the waveplates I minimized the reflected light, giving strongly p-polarized light on the AS table for best results when interfering with the IFO beam. I wiggled the fiber and found no strong dependency of the output polarization on fiber bending. Attachment 2 shows the current layout.

The beat signal between AUX and PSL table is at -20dBm, and I adjusted the PLL gain and PI-corner to get reliable locking behavior. I think it's a good idea to keep the AUX beam on the AS table blocked while it's not in use, and only unblock it when it is phaselocked to avoid a rogue beam with no fixed phase relation to the PSL in the IFO.I blocked the beam after completing this work today.

I used the signal chain that Keerthana, Koji, and I set up yesterday to look for mode flashed of the AUX light in the YARM using the RF beat with the PSL carrier in transmission. To align the AUX beam to the arm the following steps were performed:

1. Using a spectrum analyzer to look at the RF power at the target frequency between frequency-shifted AUX beam and PSL carrier on AS110, align the beam using the mirror pair closest to the fiber coupler for maximum signal.
2. Initiate a sweep of the PLL LO frequency sourced by the Marconi using GPIB scripts over about 1 FSR. A strong peak was visible at ~31.76 MHz offset frequency
3. Tune and hold LO frequency (in this case at 48.2526 MHz) such that AUX beam resonates in the arm. Optimize alignment by maximizing RF signal on PD in transmission.

This was followed by a sweep over two full FSRs. Attachment #1 shows the trace recorded by the AG4395 using the max data hold setting during the sweep. Essentially the beat between AUX and PSL carrier traced out the arm's transmission curve. At minimum transmission there was still a ~82dB beat on the transmission PD visible.

The YEND QPD is currently blocked and sees no light.

Given the various changes to the IFO config since last Thursday when I was last able to lock the DRMI, I wanted to try once again tonight. However, I had no success. By my judgement, the alignment is fine as judged by looking at mode flashes on the cameras. However, despite following the usual alignment procedures, I did not get a single lock in tonight.

Perhaps we can use a flip mount on the BS that combines the PSL and AUX beams on the AS table, so we have the option of recovering the usual IFO config when we so desire - while Jon needs the SRC locked for his measurement, it would be nice to not have to figure out the correct demod phases etc each time there is a change in the optical setup of the AUX beam.

Unfortunately, this has happened (and seems like it will happen) enough times that I set up a script for rebooting the machine in a controlled way, hopefully it will negate the need to repeatedly go into the VEA and hard-reboot the machines. Script lives at /opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh. SVN committed. It worked well for me today. All applicable CDS indicator lights are now green again. Be aware that c1oaf will probably need to be restarted manually in order to make the DC light green. Also, this script won't help you if you try to unload a model on c1lsc and the FE crashes. It relies on c1lsc being ssh-able. The basic logic is:

1. Ask for confirmation.
2. Shutdown all vertex optic watchdogs, PSL shutter.
3. ssh into c1sus and c1ioo, shutdown all models on these machines, soft reboot them.
4. ssh into c1lsc, soft reboot the machine. No attempt is made to unload the models.
5. Wait 2 minutes for all machines to come back online.
6. Restart models on all 3 vertex FEs (IOPs first, then rest).
7. Prompt user for confirmation to re-enable watchdog status and open PSL shutter.

I was checking on the slow machine channels and found something I could not understand.

On the IOO WFS HEAD screen, there are two sets of 4 switches (magenta rectangles in Attachment 1) labeled 2/4/8/16dB.
But as far as I could confirm with the WFS demod (D980233) and WFS head (D980012) drawings, they are the gain (attenuation) switches for the individual segments.
Their epics variable names are "C1:IOO-WFS1_SEG1_ATTEN", "C1:IOO-WFS1_SEG2_ATTEN", etc...

I confirmed the switches are alive (effective), and they are not all ON or OFF. I wonder what is the real situation there...

Aim: To develop a neural network in order to correlate the intensity fluctuations in the scattered light to the angular motion of the test mass. A block diagram of the technique employed is given in Attachment 1.

I have used Keras to implement supervised learning using neural network (NN). Initially I had developed a python code that converts a video (59 sec) of scattered light, after an excitation (sine wave of frequency 0.2 Hz) is applied to ETMX pitch, to image frames (of size 480*720)  and stores the 2D pixel values of 1791 images frames captured into an hdf5 file. This array of shape (1791,36500) is given as an input to the neural network. I have tried to implement regular NN only, not convolution or recurrent NN. I have used sequential model in Keras to do this. I have tried with various number of dense layers and varied the number of nodes in each layer. I got test accuracy of approximately 7% using the following network. There are two dense layers, first one with 750 nodes with a dropout of 0.1 ( 10% of the nodes not used) and second one with 500 nodes. To add nonlinearity to the network, both the layers are given an activation function of tanh. The output layer has 1 node and expects an output of shape (1791,1). This model has been compiled with a loss function of categorical crossentropy, optimizer = RMSprop. We have used these since they have been mostly used in the image analysis examples. Then the model is trained against the dataset of mirror motion. This has been obtained by sampling the cosine wave fit to the mirror motion so that the shapes of the input and output of NN are consistent. I have used a batch size ( number of samples per gradient update) = 32 and epochs (number of times entire dataset passes through NN) = 20. However, using this we got an accuracy of only 7.6%. 

I think that the above technique gives overfitting since dense layers use all the nodes during training apart from giving a dropout. Also, the beam spot moves in the video. So it may be necessary to use convolution NN to extract the information.

The video file can be accesses from this link https://drive.google.com/file/d/1VbXcPTfC9GH2ttZNWM7Lg0RqD7qiCZuA/view.

Gabriele told us that he had used the beam spot motion to train the neural network. Also he informed that GPUs are necessary for this. So we have to figure out a better way to train the network.  

gautam noon 11Jun: This link explains why the straight-up fully connected NN architecture is ill-suited for the kind of application we have in mind. Discussing with Gabriele, he informed us that training on a GPU machine with 1000 images took a few hours. I'm not sure what the CPU/GPU scaling is for this application, but given that he trained for 10000 epochs, and we see that training for 20 epochs on Optimus already takes ~30minutes, seems like a futile exercise to keep trying on CPU machines.

The values obtained from both analytical and finesse solution is given in the above table along with the corresponding percentage errors.finesse1.pdf

The parameters used for this calculation are listed below.

Parameter	Value
length of the cavity (L)	38.5 m
Wavelength of the laser beam ()	1064 nm
Radius of curvature of ITM (R1)
Radius of curvature of ETM (R2)	58 m

The cavity scan data obtained from Finesse is also attached here.

As of now, I have made the codes needed to sweep the marconi frequency for taking the cavity scan data, the photo diode at the y-end is conected to the spectrum analyser already and I also have the finesse simulation of the Ideal Fabry-perot cavity. By seeing my last elog entry, Gautam suggested me that I need to take a different approach for estimating the FSR and TMS value from the Finesse graph. That is, by using least square fit models. Now I am trying to do that and get a better estimate of the error values. Based on my understanding I am dividing this project into various tasks.

1. Getting a better estimate of the error value by using least square fits. Also plotting a graph of frequency Vs mode number and finding the value of Free Spectral Range from its slop.

2. Inserting zernike polynomials to the Finesse simulation and with the help of least square fit, plotting the graph of frequency Vs mode number. Understanding the shifts from the Ideal graph we obtained from step 1. Using this data, plotting the phase map corresponding to this.

3. Repeating step 2 by taking different zernike polynomials and creating a data base which will be useful for the analysis of the real data. This will also prepare me to do the fitting models easily.

4. Collecting data from the IFO and applying these fitting models to it. Finding the set of zernike polynomials which are similar to the actual fugure error of the mirror. Plotting the Phase map corresponding to those zernike polynomials.

If you feel that there is some mistake in the steps, please correct me. It will be really helpful!

Aim: To calibrate CCD of GigE using LED1050E.

The following table shows some of the specifications for LED1050E as given in Thorlabs datasheet.

 The circuit diagram is given in Attachment 1.

Considering a power supply voltage V_cc = 15V, current I = 20mA & forward voltage of led V_F = 1.25V, resistance in the circuit is calculated as,

R = (V_cc - V_F)/I = 687.5

Attachment 2 gives a plot of resistance (R) vs input voltage (V_cc) when a current of 20mA flows through the circuit. I hope I can proceed with this setup soon.

Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?