[Yuta, Mayank]

UPDATE: It turned out that the pair of 0.3 OD ND filters we used were not matched. So we replaced them with new 0.5 OD NENIR05A-C from thorlabs. Now both the photodiodes give similar count.

The DC power incident on the PDs is 74 mW which may cause saturation. We attenuated the beam going to BHD_DC Photodiodes using ND filter of OD 0.3 which gives attenuation of 0.5. 

[Mayank, Radhika, Paco]

We locked PRMI for a solid hour and controlled LO phase angle using BH55_Q at higher power.

After Radhika aligned the IFO for us, and recovered the PRMI flashing (using REFLDC), we attempted a PRMI lock. After a few trials we succeeded.

Control parameters: see Attachment #1, basically REFL11_I to PRCL, and AS55_Q to MICH (error points) and actuation as previous locks with PRCL to PRMand MICH to 0.5 * BS - 0.33 * PRM.

The gains are slightly different, and in particular PRCL gain was increased from -0.07 to -0.09 after an OLTF estimated the UGF could be increased to > 120 Hz (Attachment #2 shows the measured OLTF) Do note we ended up disabling the FM1 on PRCL LSC filter bank (a boost) because we thought the loop was unstable when it got triggered ON. Finally, we took a quick noise spectrum of PRMI, and we have yet to calibrate it.

We also managed to reduce the AS_DC level from 0.4 to 0.1. We first tried to add an offset to MICH error point but the trick was to align the ITMX ITMY differential yaw.

Lock start Time: 1367107965 --> 1367111565

While PRMI was locked, we quickly locked homodyne angle using BH55_Q. For this the demod angle was optimized from -60 deg to 55.374 deg. The lock was acquired using FM5 and FM8 with a gain of -0.75. Attachment #3 shows the "calibrated" noise budget of the LO phase under this configuration. The main difference with respect to the previous  budget is in the "RIN" which we now realize is not relative... therefore the increase in this budget. We will revisit this calibration later.

- Next steps

• Re-calibrate LO phase noise with high power
• Investigate BH44 control
• Calibrate PRMI noise for budget
• Estimate LO phase sensitivities at MICH vs PRMI

We removed the PSL controller internal (broken) fans after it tripped due to overheat.

Background

[Mayank, Radhika]

While aligning Xarm I noticed sudden loss of beam. On Radhikas suggestion we cheked the PSL and found out that the PSL controller was in off state (No lights on front and back panel). We restored the situation by unplugging and replugging the power cord. The PSL worked fine for a few minutes (~ 30 ) and then tripped again.This time the front panel  OFF light was on . See attached image (Attachment #1).

Fix

[Paco, Mayank, Koji-remote]

We disconnected the PSL controller and took this opportunity to investigate the controller's internal cooling mechanism. After disassembling the top panel of the chassis, we saw there are two SUNON - KD1205PHB2 fans meant to run at 12 VDC (1.7 W) connected to the bottom pcb inside the controller. After disconnecting them from this board, we tested them with an externally supplied dc voltage and confirmed they no longer worked. We noted the cooling mechanism is based on a long aluminum heat sink to which most ICs are attached, and the fans are meant to provide airflow towards the rear aperture on the chassis. We followed Koji's suggestion and for now, removed the damaged components (detailed pictures of this operation have been posted in a google photos album elsewhere) to allow heat to flow out more easily.  We reassembled the controller chassis and reinstalled it with the external fan providing the necessary airflow to prevent the unit from tripping again due to overheating. Then we turned on PSL and recovered PMC and IMC locks.

Aftermath

We took a C1:IOO-MC_F_DQ trace after this work to confirm our earlier findings; the trace is attached in Attachment #2. The noise bumps are present as expected. This is still not a desirable configuration so next step would be replacing the external fan, or even better, find the appropriate spare of the internal units and berid the external one.

[Radhika, Mayank]

Restarted the NDS2 script on Megatron following the instructions here

Steps  
1) SSH to megatron - "ssh megatron"

2) Switch to nds2mgr using "sudo su nds2mgr" 

3) Stop and restart the service using 

"sudo /etc/init.d/nds2 stop
sleep 20
sudo /etc/init.d/nds2 start" 

[Mayank, Koji]

We aligned the ETMX with help of reflection of green beam from the ETMX. 

ITMX was aligned with Michelson fringe.

We could see the flashing of green HOM and the flashing of IR. However there was no signal at TRX. This is beacuse we have not connected the Higain PD yet.  In oder to use the QPD signal instead of Higain PD we set a negative threshold of PD selection.

We were able to see the flasing on the ndscope and the adgusted the ITMX and ETMX aligment to improve the transmission.

Even with high transmission we were not able to get any locking with ETMX actuation. We shifted to ITMX actuation and doubled the gain  to lock the Xarm.

To explore this assymettery in ETMX and ITMX actuation. We measured the transfer function of C1:SUS-ITMX_LSC_EXC to C1:LSC-XARM_IN1 and C1:SUS-ETMX_LSC_EXC to C1:LSC-XARM_IN1.  (Attachment #1). The TFs look different.

This could be because the Anti-De-Whitening is not yet updated for the ETMX new coil driver.        

To Do:

• Shift the boards on the rack.
• Connect BNC board to interface HighGainPD, Green ReFL etc.
• Recover the Suspension and OPlev functions.
• Update the AntiDewhitening Filter

After lots of burtrestores and alignment by Koji. The interferometer is live again.

The X/Y green beams are resonating. The X/Y arms were locked with IR. We saw the MI fringe on the POP. However, the AS spot is not visible. Needs to check the optical table?
 

The auto-restoration process did not bring back all the settings (incomplete restoration), and we had to restore them manually. We took some time to realize it.

[Paco, Mayank]

The Y arm was locked. It remained locked for 15 Hrs except for a short glitch.

1) Choosing the target signal: It is the signal which we would like to minimize by filtering. 
   'C1:ALS-BEATY_FINE_PHASE_OUT_HZ_DQ' Beat Frequency (which represent length fluctuation of locked arm cavity) was chosen to be the target signal. 

2) Choosing the Witness signal: This was chosen by measuring coherence between the Target signal and various possible Witness signals 
(SEIS_EY_X_OUT, SEIS_EY_Y_OUT, SEIS_BS_Y_OUT, SEIS_BS_X_OUT, ACC_MC1_X_OUT and ACC_MC1_Y_OUT). 
The witness signal SEIS_EY_X_OUT has the maximum coherence with the Target signal hence it was chosen to be the Witness signal.
Witness signal channel : 'C1:PEM-SEIS_EY_X_OUT_DQ' (X Channel of Seismometer at Y end)

3) Calculation of Weiner Filter

    Both the signals were down sampled to 64 Hz. The data for the first 150 minutes starting from (GPS START TIME: 1370224294) was split into 50 sections of 3 minutes each.
    A Weiner filter is calculated based on Target and Witness data of the first section (i.e. first 3 minutes of Target and Witness signal). 
    This calculated Weiner filter is then applied to witness data on the succesive sections. 

Figure 0 shows the Yarm transmission vs time.

Figure 1 shows the coherence between the two signals (Target and Witness) with the passage of time.

Figure 2-7
Blue curve = Target signal
Orange Curve= Tartget signal - Filtered Witness signal  

Observation: 
The coherence decays with time.(why? Probably because a common signal is adding/ influencing both of these signal which eventually decreases with time).
As long as the coherence is sufficient (>.2) the Weiner filter helps in reduction of target signal.

I  measured the transfer function of the new coil driver board. This was done to estimate the correct Sim-Dewhithinng and Anti-Dewhitening digital filters in the CDS. 

Attachment 1: Shows the setup used to measure the TF of the Coil driver board.
Attachment 2: Coil driver board replaced by a DB9 cable (Reference).
Attachment 3: The magnitude and phase response of the measured and simulated TF (Coil driver parameters mentioned here (D2100145) )

Update

Attachment 4: The magnitude and phase response of the simulated and measured TF for the two operating modes. (The coil driver has two modes of operation i.e. Run and Acuisition)

I modified the Binary Input DB9 connector. The coil drivers are now operating with the Run/Acq LED off. As per 17656 they should have a flat TF now.

Using the three Marconis in 40m at 11.1 MHz, the Three Cornered Hat technique was used to find the individual noise of each Marconi with different offset ranges and the direct/indirect frequency source of the rubidium clock.

Rana explained the TCH technique earlier - by measuring the phase noise of each pair of Marconis, the individual phase noise can be calculated by:

S1 = sqrt( (S12^2 + S13^2 - S23^2) / 2)

S2 = sqrt( (S12^2 + S23^2 - S13^2) / 2)

S3 = sqrt( (S13^2 + S23^2 - S12^2) / 2)

I measured the phase noise for offset ranges of 1Hz, 10Hz, 1kHz, and 100kHz (the maximum allowed for a frequency of 11.1Mhz) and calculated the individual phase noise for each source (using 7 averages, which gives all the spikes in the individual noise curves). The noise from each source is very similar, although not quite identical, while the noise is greater at higher frequencies for higher offset ranges, so the lowest possible offset range should be used. It appears the noise below a range of 10Hz is fairly constant, with a smoother curve at 10Hz.

The phase noise for direct vs indirect frequency source was measured with an offset range of 10Hz. While very similar at high and low frequencies for all 3 Marconis, the indirect source was consistently noisier in the middle frequencies, indicating that any Marconis connected to the rubidium clock should use the rubidium clock as a direct frequency reference.

Since I can't adjust settings of the Marconis at the moment, I have yet to finish measurements of the phase noise at 160 MHz and 80 MHz (those used in the PSL lab), but using the data I have for only the first 2 Marconis (so I can't finish the TCH technique), the phase noise appears to be lowest using the 100kHz offset except at the higher frequencies. The 160 MHz signal so far is noisier than the 11.1 MHz signal with offset ranges of 1 kHz and 10 Hz, but less noisy with a 100 kHz offset.

I still haven't measured anything at 80 MHz and have to finish taking more data to be able to use the TCH technique at 160 MHz, then the individual phase noise data will be used to measure the noise of the function generators used in the PSL lab.

Rana and I

1) took the temperature sensors off the reference cavity;

2) wrapped copper foil around the cavity (during which I learned it is REALLY easy to cut hands with the foil);

3) wrapped electrical tape around the power terminals of the temperature sensors (color-coded, too! Red for the out of loop sensor, Blue for the first one, Brown for the second, Gray for the third, and Violet for the fourth. Yes, we went with an alphabetical coding system, excluding the out of loop sensor);

4) re-wrapped the thermal blanket heater;

5) covered the ends of the cavities with copper, ensuring that the beam can enter and exit;

6) took pretty pictures for your enjoyment!

We will see if this helps the temperature stabilization of the reference cavity.

The end of the reference cavity, with a lovely square around the beam.

The entire, well-wrapped reference cavity!

Using the equation for thermal resistance

R_thermal = L/(k*A)

where k is the thermal conductivity of a material, L is the length, and A is the surface area through which the heat passes, I could find the thermal resistance of the copper and stainless steel on the reference cavity. To reduce temperature gradients across the vacuum chamber, the thermal resistance of the copper must be the same or less than that of the stainless steel. Since the copper is directly on top of the stainless steel, the length and width will be the same for both, just the thickness will be different (for ease of calculation, I assumed flat, rectangular strips of the metal). Assuming we wish to have a thermal resistance of the copper n times less than that of the stainless steel, we have

R_Cu = R_SS/n

or

L/(k_Cu*w*t_Cu) = L/(k_SS*w*t_SS*n)

so that

t_Cu/t_SS = n*k_SS/k_Cu

We know that k_SS = 401 W/m*K and K_Cu = 16 W/m*K, so

t_Cu/t_SS = 0.0399*n

By using the drawings for the short reference cavity vacuum chamber (the only one I could find drawings for online) I found a thickness of the walls of 0.12 in or 0.3048 cm. So for the same thermal resistance in both metals, the copper must be 0.0122 cm thick and for a thermal resistance 10 times less, it must be 0.122 cm thick. So we will have to keep wrapping the copper on the vacuum chamber!

We rebooted c1iovme because the lines stopped responding to inputs on C1:I00-MC_DRUM1. This fixed the problem.

 No new stuff for these computers.  Everything should be installed already.

Here's my first hysteresis model in Simulink. It's based on the equation y=Amplitude*sin(frequency*t+phase)+(hysteresis/frequency²) as a solution to y''+frequency²*y+hysteresis=0. All values in the model are variables that should be manipulated through the model workspace or external code.

A better hysteresis model based on the simple harmonic oscillator equation. Useless variables have been removed and output can now be saved to workspace for plotting. The model is at "/users/mjenson/matlab/SHO_hyst.mdl".

Here are the hysteresis plots from the most recent model, which uses a modified harmonic oscillator equation y''=-(Frequency)²*y-Hysteresis.  The hysteresis constant seems to change both the amplitude and equilibrium point of the pendulums, which is akin to changing the length of a pendulum without changing the frequency. This does not make sense. Perhaps the hysteresis value should be moved to the "spring" constant for the pendula and not restricted to a position-biasing value.

I accidently shut off the laser at 19:34 with the emergency shutoff button while trying to tap into a video line for the Sensoray device.

The Sensoray device is currently viewing Monitor 4 and plugged into Pianosa.  The user interface is run at /home/controls/Downloads/sdk_2253_1.2.2_linux/python demo.py. It can preview and capture the video stream, however the captured files are terrible. I believe it has something to do with the bitrate, since the captured video with lower bitrates are not as bad as the ones with higher bitrates, but  I am not certain.

 Turns out that the "MPEG-4 VES" video format is just bad for captured video.  Everything except "MP4" and "MPEG-TS" works for streaming, and "MP4" and "MPEG-TS" seem to be the only captured formats that can be viewed properly.

 The new hysteresis model is slightly based on the SHO equation, but with the force being out of phase with the position by an amount of hysteresis {x(t)=Amp*sin(freq*t), F(t)=Amp*sin(freq*t+Hyst)}. The new model can be found at /users/mjenson/matlab/hyst_v_3.mdl.  Pictures are: new hysteresis model, x(t) subsystem in new model[xh''(t) only lacks -1 multiplier and includes hysteresis variable], new plots.

I replaced the projector video and power cables with longer ones, and zip-tied them to the ceiling and wall so they don't block the image.

The highest resolution available is 720x480 pixels. Bit depth of captured images and video is most likely 16 bits per pixel. Video may be captured raw as well, which will be necessary for image subtraction/enhancement, however it cannot currently be played raw. A captured image is shown below, along with MP4 video.

The new hysteresis model uses a triangle wave with offset zero points as the position function and a sinusoidal force function, creating a loop similar to this. Model is at /users/mjenson/matlab/ferro_hyst.mdl.

I've upgraded the Sensoray GUI so it can now switch the video channel it receives, thanks to the videoswitch script.

I acquired 2 raw frames of MC2 using "/users/mjenson/sensoray/sdk_2253_1.2.2_linux/capture -n -s 720x480 -f 1", one while the laser was off the mode cleaner and another while it was on:

I then used "/users/mjenson/sensoray/sdk_2253_1.2.2_linux/imsub/display-image.py" to generate bitmaps of the raw images, which I then subtracted using the Python Imaging Library to generate a new image:

It doesn't look all that different, but the first image didn't have that much lit up in it to begin with. I should be able to write a script that does all of this without needing to generate new files in between acquisition and subtraction.

Video Capture with the Sensoray works again. Pianosa just needed mplayer installed for it to play properly.

To capture video with the Sensoray, open the GUI (python ./demo.py), simply press "Save," enter a filename, and hit "Stop" when you wish to stop recording. If you want to change the video format, there is a dropdown menu labelled "Format." I recommend MP4 for standard video, and nv12 for RAW video.

**EDIT:** Mixed up X and Y. Beam is 3.5844 mm tall and 2.7642 mm wide

14.112 hundredths of an inch in the vertical direction

3.5844 millimeters

10.883 hundredths of an inch in the horizontal direction

2.7642 millimeters

Plots and error bars to come soon.

Results of the Razor Blade Beam Scan

The horizontal blade test measured the beam intensity as a razor blade passed in between it and a power meter from the left side of the beam (negative x values) until blocking it. The resulting function, found through least-squares regression of the error function, calculates a beam height of 3.6 mm +/- 16 mm. However, the function has a chi-squared value of 3.2, so that value may not be accurate.

The vertical blade test measured beam intensity as a razor moved from below the beam (negative x values) until blocking it. This function, found the same way as above, calculates a beam width of 2.8mm +/- 9.6 mm, and has chi-squared value of 0.77.

Both data sets have a y-error of 0.5 micro-Watts, and an x-error of 0.127 mm. The Python code used to analyze the data and plot the results is attached.

Unaltered PR2 images, with IR card, without card, and steering mirror:

Unaltered POX and POY images:

The POX images only needed a major brightness reduction and increased contrast to view:

The POY images needed their intensity histograms shifted slightly right and made left-tailed:

Went through all of Pooja's elog posts, her report and am currently cleaning up her code and working on setting up the simulations of spot motion from her work last year. I've also just begun to look at some material sent by Gautam on resonators.

This week, I plan to do the following:

1) Review Gabriele's CNN work for beam spot tracking and get his code running.

2) Since the relation between the angular motion of the optic and beam spot motion can be determined theoretically, I think a neural network is not mandatory for the tracking of beam spot motion. I strongly believe that a more traditional approach such as thresholding, followed by a hough transform ought to do the trick as the contours of the beam spot are circles. I did try a quick and dirty implementation today using opencv and ran into the problem of no detection or detection of spurious circles (the number of which decreased with the increased application of median blur). I will defer a more careful analysis of this until step (1) is done as Gautam has advised.

3) Clean up Pooja's code on beam tracking and obtain the simulated data.

4) Also data like this  (https://drive.google.com/file/d/1VbXcPTfC9GH2ttZNWM7Lg0RqD7qiCZuA/view) is incredibly noisy. I will look up some standard techniques for cleaning such data though I'm not sure if the impact of that can be measured until I figure out an algorithm to track the beam spot.

A more interesting question Gautam raised was the validity of using the beam spot motion for detection of angular motion in the presence of other factors such as surface irregularities. Another question is the relevance of using the beam spot motion when the oplevs are already in place. It is not immediately obvious to me how I can ascertain this and I will put more thought into this.

I have done the following thus far since elog #14626:

Simulation:

1. Cleaned up Pooja's code for simulating the beam spot. Added extensive comments and made the code modular. Simulated the Gaussian beam spot to exhibit 
   1. Horizontal motion
   2. Vertical motion
   3. motion along both x and y directions:
2. The motion exhibited in any direction in the above videos is the combination of four sinusoids at the frequencies: 0.2, 0.4, 0.1, 0.3 Hz with amplitudes that can be found as defaults in the script ((0.1, 0.04, 0.05, 0.08)*64 for these simulations.). The variation looks as shown in Attachment 1. For the sake of convenience I have created the above video files with only a hundred frames (fps = 10, total time ~ 10s) and this took around 2.4s to write. Longer files need much longer. As I wish to simply perform image processing on these frames immediately, I don't see the need to obtain long video files right away.
3. I have yet to add noise at the image level and randomness to the motion itself.  I intend to do that right away. Currently video 3 will show you that even though the time variation of the coordinates of the center of the beam is sinusoidal, the motion of the beam spot itself is along a line as both x and y motions have the same phase. I intend to add the feature of phase between the motion of x and y coordinates of the center of the beam, but it doesn't seem all too important to me right now. The white margins in the videos generated are annoying and make tracking the beam spot itself slightly difficult as they introduce offset (see below). I shall fix them later if simple cropping doesn't do the trick.
4. I have yet to push the code to git. I will do that once I've incorporated the changes in (3).

Circle detection:

1. If the beam spot intensity variation is indeed Gaussian (as it definitely is in the simulation), then the contours are circular. Consequently, centroid detection of the beam spot reduces to detecting these contours and then finding their centroid (center). I tried this for a simulated video I found in elog post 14005. It was a quick implementation of the following sequence of operations: threshold (arbritrarily set to 127), contour detection (video dependent and needs to be done manually), centroid determination from the required contour.  Its evident that the beam spot is being tracked (green circle in the video). Check #Attachment 2 for the results. However, no other quantitative claims can be made in the absence of other data.
2. Following this, Gautam pointed me to a capture in elog post 13908. Again, the steps mentioned in (1) were followed and the results are presented below in Attachment #3. However, this time the contour is no longer circular but distorted. I didn't pursue this further. This test was just done to check that this approach does extend (even if not seamlessly) to real data. I'm really looking forward to trying this with this real data.
3. So far, the problem has been that there is no source data to compare the tracked centroid with. That ought to be resolved with the use of simulated data that I've generated above. As mentioned before, some matplotlib features such as saving with margins introduce offsets in the tracked beam position. However, I expect to still be able to see the same sinusoidal motion. As a quick test, I'll obtain the fft of the centroid position time series data and check if the expected frequencies are present.

I will wrap up the simulation code today and proceed to going through Gabriele's repo. I will also test if the contour detection method works with the simulated data. During our meeting, it was pointed out that when working with real data, care has to be taken to synchronize the data with the video obtained. However, I wish to put off working on that till later in the pipeline as I think it doesn't affect the algorithm being used. I hope that's alright (?).

1. Implemented image level noise for simulation. Added only uniform random noise.
2. Implemented addition of uniform random noise to any sinusoidal motion of beam spot.
3. Implemented motion along y axis according to data in "power_spectrum" file.
4. Impelemented simulation of random motion of beam spot in both x and y directions (done previously by Pooja, but a cleaner version).
5. Created a video file for 10s with motion of beam spot along the y direction as given by Attachment #1. This was created by mixing four sinusoids at different amplitudes (frequencies (0.1, 0.2, 0.4, 0.8) Hz Amplitudes as fractions of N = 64 (0.1 0.09 0.08 0.09). FPS = 10. Total number of frames = 100 for the sake of convenience.  See Attachment #5.
6. Following this, I used the thresholding (threshold = 127, chosen arbitrarily), contour detection and centroid computation sequence (see Attachment #6 for results) to obtain the plot in Attachment 2 for the predicted motion of the y coordinate. As is evident, the centering and scale of values obtained are off and I still haven't figured out how to precisely convert from one to another.
7. Consequently, as a workaround, I simply normalised the values corresponding to each plot by subtracting the mean in each case and dividing the resulting series of values by their maximum. This resulted in the plots in Attachments 3 and 4 which show the normalised values of y coordinate variation and the error between the actual and predicted values between 0 and 1 respectively.

Things yet to be done:

Simulation:

1. I will implement the mean square error function to compute the relativer performance as conditions change.
2. I will add noise both to the image and to the motion (meaning introduce some randomness in the motion) to see how the performance, determined by both the curves such as the ones below and the mean square error, changes.
3. Following this, I will vary the standard deviation of the beam spot along X and Y directions and try to obtain beam spot motion similar to the video in Attachment #2 of elog post 14632.
4. Currently, I have made no effort to carefully tune the parameters associated with contour detection and threshold and have simply used the popular defaults. While this has worked admirably in the case of the simple simulated videos, I suspect much more tweaking will be needed before I can use this on real data.
5. It is an easy step to determine the performance of the algorithm for random, circular and other motions of the beam spot. However, I will defer this till later as I do not see any immediate value in this.
6. Determine noise threshold. In simulation or with real data: obtain a video where the beam spot is ideally motionless (easy to do with simulated data) and then apply the above approach to the video and study the resulting predicted motion. In simulation, I expect the predictions for a motionless beam spot video (without noise) to be constant. Therefore, I shall add some noise to the video and study the prediction of the algorithm.
7. NOTE: the above approach relies on some previous knowledge of what the video data will look like. This is useful in determining which contours to ignore, if any like the four bright regions at the corners in this video.

Real data:

1. Obtaining real data and evaluate if the algorithm is succesful in determining contours which can be used to track the beam spot.
2. Once the kind of video feed this will be used on is decided, use the data generated from such a feed to determine what the best settings of hyperparameters are and detect the beam spot motion.
3. Synchronization of data stream regarding beam spot motion and video.
4. Determine the calibration: anglular motion of the optic to beam spot motion on the camera sensor to video to pixel mapping in the frames being processed.

Other approaches:

1. Review work done by Gabriele with CNNs, implement it and then compare performance with the above method.

1. I used the same motion as defined in the previous elog. I gradually added noise to the images. Noise added was uniform random noise - a 2 dimensinoal array of random numbers between 0 and a predetermined maximum (noise_amp). The previous elog provides the variation of the y coordinate. In this, I am also uploading the effect of noise on the error in the prediction of the x coordinate. As a reminder, the motion of the beam spot center was purely vertical. Attachement #1  is the error for noise_amp = 0, #2 for noise_amp = 20 and #3  for noise_amp = 40. While Attachment #3 does provide the impression of there being a large error, this is not really the case as without normalization, each peak corresponds to a deviation of one pixel about the central value, see Attachement #4 for reference.
2. While the error does increase marginally, adding noise has no significant effect on the prediction of the y coordinate of the centroid as Attachment #5 shows at noise_amp = 40.
3. I am currently running an experiment to obtain the variation of mean square error with different noise amplitudes and will put up the plots soon. Further, I shall vary the resolution of the image frames and the the standard deviation of the Gaussain beam with time and try to obtain simulations very close to the real data available and then determine the performance of the algorithm.
4. The following videos will serve as a quick reference for what the videos and detection look like at
   1. noise_amp = 20
   2. noise_amp = 40
5. I also performed a quick experiment to see how low the amplitude of motion could be before the algorithm falied to detect the motion and found it to occur at 2 orders of magnitude below the values used in the previous post. This is a line of thought I intend to pursue more carefully and I am looking into how opencv and python handle images with floats as coordinates and will provide more details about the previous trial soon. This should give us an idea of what the smallest motion of the beam spot that can be resolved is.

The following steps summarize the steps to setting up and interacting with a GigE camera.

Launching the PylonViewerApp:

1. Open a new terminal using Ctrl + Alt + T on the keyboard.
2. Launch the app using the command pylon.

Using setup python scripts to interact with the GigE (a summary of the steps listed here and here)

1. Connect the GigE camera to the ethernet cable and record its IP address. If the IP address is not printed on the GigE, launch the PylonViewerApp and navigate to the "Tools" dropdown menu and select "pylon IP configurator" to be presented with a list of all connected cameras and their IP addresses.
2. To simply observe the camera feed, open a new terminal and run the following commands:
   1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
   2. python camera_server.py -c C1-CAM-ETMX.ini  (only one config file is present currently and more will be added as more cameras are set up. The "Camera IP" in the  .ini file must match that determined in step 1). This starts the camera server.
3. Open a new tab (Ctrl + Shift + T on the keyboard) in the terminal. You should still be in the same directory as navigated to in step 2.1. Run the following command.
   1. python camera_client.py -c C1-CAM-ETMX.ini
4. This should bring up a feed from the camera. Close at will.
5. To record a video file, repeat steps 1 and 2. Open a new tab as described in step 3. Then run the following command:
   1. python camera_client_movie.py -c C1-CAM-ETMX.ini
6. Enter the full path to the file where you wish to save the movie in the prompt that appears. Use ./your_file_name_here.avi to save the the video in the working directory. Press Ctrl + C to stop recording. The recording can be played by navigating to the location where the recording is stored and running vlc your_file_name_here.avi.
7. To adjust the exposure setting of the camera, open a new terminal and run the command sitemap . This should bring up the medm display in Attachment #1. Click on the Video/Lights button highlighted in red and select GigE. Adjust the exposure value in the next window using the slider before starting the server in step 1. Adjusting the slider once the server is started causes the program to freeze. Also set the Snapshot channel C1:CAM-ETMX_SNAP to off as mentioned in elog 14037.

Upcoming updates:

1. Automatic script to run the above steps.
2. Pre-determining the time duration of the recorded video.
3. Obtaining snapshots.

I was working with the git repo in the SnapPy_pypylon folder (/cvs/cds/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon) and needed to create a branch. To avoid any confusion, I modified the PS1 variable and that alone in the bashrc file to reflect the git branch so that the prompt now displays the git branch if you enter a repository. This is just an update.

Figured out how to get/grab frames by looking at the pypylon documenation as that turned out to be easier than modifying Jon's code. Still not sure about how to modify the exposure time (other than using the pylon app, the only technique I know so far is to adjust the exposure manually on the medm screen and then run the scripts as described in the previous elog). I will figure that out tomorrow and make a script suitable for Kruthi's usage (obtain a bunch of images with different exposure times). I will also try and integrate the video saving and streaming code into this and have a neat little script set up asap.

Thanks! It does indeed do the trick! With that I was able to

1. Obtain current exposure value using the terminal command caget C1:CAM-ETMX_EXP
2. Set exposure value using the terminal command caput C1:CAM-ETMX_EXP <desired_exposure_value>

Further, a quick look at the camera server code in /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_server.py revealed that the script expects the details of "Number of Snapshots" in "Camera Settings" in the configuration file i.e in C1-CAM-ETMX.ini at ( /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini) which wasn't present before. Adding this parameter to the config file allows one to take a snapshot using the medm screen. Infact, unlike as described in this elog, I was able to start the server and client as described in elog 14649, and then obtain snapshots using the terminal command  caput C1:CAM-ETMX_SNAP 1.

[Koji, Milind]

Today I ran into the following errors:

1. Inability to access the EPICS channels using the commands caget and caput and thus the generation of a blank medm screen (error in Attachment #1) when simultaneously running the code in camera_server.py (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_server.py).
2. Inability to run camera_server.py code with an active medm screen with a "... failed to read <EPICS channel>" error.

Therefore, Koji and I took a look at it and putting our faith in Gautam's hunch from elog 13023, we walked down to rack 1Y1 and keyed it. Following this, all the functionality previously described was restored! Koji then took a look at all the channels handled by this machine and bestowed upon me the permission to key the crate should I lose control of the GigE again.

Steps to take snapshots using GigE at different exposures [Instructions for Kruthi]:

1. Setup C1-CAM-ETMX.ini (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini) appropriately. The parameter Number of Snapshots determines how many snapshots will be taken at any given exposure. Set Name Overlay, Time Overlay, Calculation Overlay, Calculations (if using very low values of exposure) and Auto Exposure to False. Ensure that that the IP address of the Camera in use and that in the configuration file match.
2. Launch a server using the following commands (as described in elog 14649)
   1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
   2. python camera_server.py -c C1-CAM-ETMX.ini
3. Open another terminal in the same directory and then run the following command
   1. python exposure_variation.py --minval <minval> --maxval <maxval> --step <step> where
      1. minval: lower bound of range of exposure values, defaults to 150
      2. maxval: upper bound of range of exposure values, defaults to 100000
      3. step: step size of variation in the range [minval, maxval], defaults to 2000

The python script takes in the above parameters and then takes snapshots by setting the exposure to values starting at minval and going upto maxval incrementing by step at each turn. This uses a simple for loop and is nothing elaborate.

A few unrelated updates:

1. On a sidenote, I installed Sublime Text editor on rossa following the instructions at this site (check install using yum section). Further, I have also installed miniconda but did not set it up fully as I was in a rush and did not want to disturb any previously set up environment variables.
2. I have cloned Gabriele's repository and am trying to get it to work on my system. As Gautam has pointed out that the end goal is to get stuff working on the lab machines, I will sharea .yml file with the necessary environment details upon completion.
3. I will upload details of how I am going to construct the two learning tasks that Rana, Gautam and I discussed in a day or two including details of the use of simulation data for training data in the absence of real data (until Kruthi is done setting up the GigE) which Gautam suggested I do to speed things up.