40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 243 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  5259   Thu Aug 18 00:53:48 2011 jamie, kiwamu, suresh, jenneUpdateGeneralPUMP PLAN ABORTED; need to work more on IFO alignment

We have decided that the IFO alignment is bad enough that we're not ready to pump down.  PUMP ABORTED.

The IFO alignment is somewhat OK, in that the green and IR beams are flashing in the arms, and the return beams are overlapping at the BS.  However the beams appear to be not centered on any of the optics at the moment.  They are all displaced in yaw by ~0.5 to 1 cm or so in various directions.

From this we have decided that we need to step back and reattack the IFO alignment from square one.  Here is our current suggested procedure:

  1. check ETM positions relative to what we think they should be on the drawings.  This is to verify that the ETMs were not placed in the wrong places laterally.
  2. translate Y green axis north, centering green on ETMY and ITMY (by looking at cards).  North is the opposite direction from how the beams are displaced from the TM centers.
  3. steer input pointing to overlap IR on green beam at BS, ITMY, and ETMY.  IR should visibly overlap green at both BS and ITMY, and we should be able to see IR on target in front of ETMY with ETMY face camera, and in ETMY trans camera.
  4. center IR on ETMX by steering BS with DC bias.
  5. align Y arm cavity for green resonance by adjusting ITMY.
  6. adjust ITMX to achieve michelson fringes at AS
  7. adjust PRM lateral translation to center beam on PRM, if needed
  8. adjust SRM lateral translation to center beam on SRM, if needed
  9. align PRC to see fringes
  10. align SRC to see fringes
  11. extract AS (no clipping)

 Once this is done, we will need to check the following:

  • IPANG/IPPOS extraction
  • pick-off extraction
  • OPLEVs
  • OSEMs
  • green periscopes and green beam extraction at PSL

We've decided to stop for the night, get a good nights rest, and attack all of this tomorrow morning.

Beam_spot_shifts.png

  5258   Wed Aug 17 20:14:49 2011 jamie, kiwamu, suresh, jenne, keiko, anamariaUpdateGeneralin-vacuum work status, prep for pump

This afternoon's work:

  • OSEMs were adjusted on all suspended optics.
  • X and Y-arms were aligned to green.
  • Once that was done, the input pointing was adjusted with the PZTs to get the IR beam centered on ITMY and ETMY.
  • Once the input pointing was ok we extracted IPANG and IPPOS.
  • BS, ITMY, PRM, SRM optical levers (oplevs) were extracted.
  • Prepared rails and stops for TMs for morning drag wiping.

TODO before drag wiping:

  • Check full IFO alignment.
  • Readjust OSEMs if needed.
  • Extract ITMX oplev.
  7599   Tue Oct 23 17:30:33 2012 jamie, nic, jenne, raji, manasaUpdateAlignmentInitial attempts to fix IFO alignment

We went into the vertex today to see about fixing the alignment.  The in-air access connector is in place, and we took heavy doors off of BS, ITMY, and ETMY chambers.

We started by looking at the pointing from the PZTs.  Manasa and Raji hooked up HV power supplies to the PZTs and set them to the middle of their ranges (75 V).

We installed a target on the BS cage, and new "free standing" targets made special by Steve for the SOSs on ITMY and ETMY.

Using a free-standing aperture target we looked at the beam height before PZT2.  It was a little high, so we adjusted it with PZT1.  Once that was done we looked at the beam height at PR2, and adjusted that height with PZT1.

We then tried to use the hysteresis in PR2 to adjust the beam height at ITMY.  Pushing just a little bit at the top or bottom of PR2 would repoint the beam in pitch.  This sort of works, but it's stupid.  Using this method we got the beam more or less centered vertically at ITMY.

We moved on to ETMY with the idea that we would again use the hysteresis in PR3 to get the vertical pointing to the ETM correct.  This was a good demonstration of just how stupid the tip-tilts really are.  Just touching slightly at the top or bottom or PR3 we could completely change the pointing at ETMY, by mili-radians (~4 cm over 40m).

At this point I cried foul.  This is not an acceptable situation.  Very little stimulation to the tip-tilts can repoint the beam inside the PR cavity.

Steve says that the TT weights, which will attach to the base of the TT mirror mounts and should help keep the mirrors vertical and not hysteretic, are being baked now and should be available tomorrow.  We therefore decided to stop what we were doing today, since we'll have to just redo it all again tomorrow once the weights are installed.

 

  9276   Thu Oct 24 09:08:27 2013 jamie.UpdateLSCPRMI + 2 ALS arms

nice.

  1898   Thu Aug 13 11:20:43 2009 janoschHowToPEMthree-channel self-noise estimation

There are two new Matlab files on the svn in /mDV/extra/C1. 'mycsd.m' is to calculate the cross-spectral density between two channels, 'csd_40T_40T_SS1.m' calls this function with the available seismic channels and derives a self-noise spectrum for the vertical axis using all three seismometers. The method requires that there are no correlations between two instruments only which is a bad idealization for certain frequencies if you have seismometers of totally different types.

'mycsd.m' uses the high-gain, low-resolution Nuttall window (built-in Matlab function 'nuttallwin.m'). High-gain windows are used for broad-band spectra like seismic spectra, but it should be exchanged by another window if you plan to look at small-bandwidth features like peaks.

Since the three-channel analysis does not require knowledge of response functions, it could be used to evaluate the performance of the adaptive filter. For example, if three channels responding to the same signal are available, then the ratio of any two csds corresponds to one of the relative transfer functions. You can then compare this function with the result produced by the adaptive filter.

  7029   Wed Jul 25 15:33:55 2012 janoschUpdateLSCringdown measurement

We did our first ringdown measurement on the Y arm. First we tried to keep the arm locked in green during the ringdown, but for some reason it was not possible to get the cavity locked in green. So we decided to do the first measurement with infrared locked only.

For the measurement we had to change the LSC model to acquire the C1:LSC-TRY_OUT_DQ at higher sampling frequency. We changed the sampling frequencies of C1:LSC-{TRX,TRY}_OUT_DQ from 2048Hz to 16384Hz.

The measurement was done at GPS 1027289507. The ringdown curve looks very clean, but there seem to be two time constants involved. The first half of the curve is influenced by the shutter speed, then curvature is changing sign and the ringdown is likely taking over. We will try to fit a curve to the ringdown part, but it would certainly be better to have a faster shutter and record a more complete ringdown.

Rindown1.png

 

  7038   Thu Jul 26 13:10:51 2012 janoschUpdateLSCmodelled ringdown

We fitted shutter and ringdown functions to the ringdown data. It is not perfectly clear how the power change due to the shutter is handed over to the power change due to ringdown. The fit suggests that the ringdown starts at a later time, but this does not necessarily make sense. It could be that the slow power decrease when the shutter starts clipping the TEM00 beam is followed by the cavity, but then the power decrease becomes too fast when the shutter reaches the optical axis and the ringdown takes over. Also, the next measurement should be taken with adjusted DC offset.

Ringdown.png

  7301   Tue Aug 28 18:28:21 2012 janoschMetaphysicsRingdownripples

Let's see if the ripples observed in the MC ringdown can be due to tilt motion of the mirrors.

The time it takes to produce a phase shift corresponding to N multiples of 2*pi is given by:

t = sqrt(2*N*lambda/(L*omega_T^2*(alpha_1+alpha_2)))

L is the length of the MC (something like 13m), and alpha_1, alpha_2 are the DC tilt angles of the two mirrors "shooting into the long arms of the MC" produced by the MC control with respect to the mechanical equilibrium position. omega_T is the tilt eigenfrequency of the three mirrors (assumed to be identical). lambda = 1.064e-6m;

The time it takes from N=1 to N=2 (the first observable ripple) is given by: tau1 = 0.6/omega_T*sqrt(lambda/L/(alpha_1+alpha_2))

The time it takes from N=2 to N=3 is given by: tau2 = 0.77*tau1

etc

First, we also see in the measurement that later ripples are shorter than early ripples consistent with some accelerated effect. The predicted ripple durations tau seem to be a bit too high though. The measurements show something like a first 14us and a late 8us ripple. It depends somewhat on the initial tilt angles that I don't know really.

In any case, the short ripple times could also be explained if the tilt motions start a little earlier than the ringdown, or the tilt motion starts with some small initial velocity. The next step will be to program a little ringdown simulation that includes mirror tilts and see what kind of tilt motion would produce the ripples exactly as we observe them (or maybe tilt motion cannot produce ripples as observed).

  7303   Tue Aug 28 19:21:37 2012 janoschMetaphysicsRingdownripples

Hmm. I don't know what ringing really is. Ok, let's assume it has to do with the pump... I don't see how the pump laser could produce these ripples. They have large amplitudes and so I always suspected something happening to the intracavity field. Therefore I was looking for effects that would change resonance conditions of the intracavity field during ringdown. Tilt motion seemed to be one explanation to me, but it may be a bit too slow (not sure yet). Longitudinal mirror motion is certainly too slow. What else could there be?

Quote:

Isn't it just a ringing of the intracavity power as you shifted the laser frequency abruptly?

Quote:

Let's see if the ripples observed in the MC ringdown can be due to tilt motion of the mirrors.

The time it takes to produce a phase shift corresponding to N multiples of 2*pi is given by:

t = sqrt(2*N*lambda/(L*omega_T^2*(alpha_1+alpha_2)))

L is the length of the MC (something like 13m), and alpha_1, alpha_2 are the DC tilt angles of the two mirrors "shooting into the long arms of the MC" produced by the MC control with respect to the mechanical equilibrium position. omega_T is the tilt eigenfrequency of the three mirrors (assumed to be identical). lambda = 1.064e-6m;

The time it takes from N=1 to N=2 (the first observable ripple) is given by: tau1 = 0.6/omega_T*sqrt(lambda/L/(alpha_1+alpha_2))

The time it takes from N=2 to N=3 is given by: tau2 = 0.77*tau1

etc

First, we also see in the measurement that later ripples are shorter than early ripples consistent with some accelerated effect. The predicted ripple durations tau seem to be a bit too high though. The measurements show something like a first 14us and a late 8us ripple. It depends somewhat on the initial tilt angles that I don't know really.

In any case, the short ripple times could also be explained if the tilt motions start a little earlier than the ringdown, or the tilt motion starts with some small initial velocity. The next step will be to program a little ringdown simulation that includes mirror tilts and see what kind of tilt motion would produce the ripples exactly as we observe them (or maybe tilt motion cannot produce ripples as observed).

 

 

  7305   Wed Aug 29 09:35:03 2012 janoschMetaphysicsRingdownripples 2

Ok, so the whole idea that mirror motion can explain the ripples is nonsense. At least, when you think off the ringdown with "pump off". The phase shifts that I tried to estimate from longitudinal and tilt mirror motion are defined against a non-existing reference. So I guess that I have to click on the link that Koji posted...

Just to mention, for the tilt phase shift (yes, there is one, but the exact expression has two more factors in the equation I posted), it does not matter, which mirror tilts. So even for a lower bound on the ripple time, my equation was incorrect. It should have the sum over all three initial tilt angles not only the two "shooting into the long arms" of the MC.

Quote:

Laser frequency shift = longitudinal motion of the mirrors

Ringing: http://www.opticsinfobase.org/ol/abstract.cfm?uri=ol-20-24-2463

Quote:

Hmm. I don't know what ringing really is. Ok, let's assume it has to do with the pump... I don't see how the pump laser could produce these ripples. They have large amplitudes and so I always suspected something happening to the intracavity field. Therefore I was looking for effects that would change resonance conditions of the intracavity field during ringdown. Tilt motion seemed to be one explanation to me, but it may be a bit too slow (not sure yet). Longitudinal mirror motion is certainly too slow. What else could there be?

 

 

  7356   Fri Sep 7 00:08:10 2012 janoschMetaphysics baffle clipping loss

With a curvature radius of about 57m for the ETMs, flat ITMs at the beam waist, and using 39m for the arm lengths, one finds that the beam radius at the ETMs is about 5.3mm. The clipping power loss of a 5.3mm beam through a 20mm radius baffle hole would be less than a ppm of a ppm if the beam was perfectly centered. If the baffle hole had 15mm radius, the clipping loss would be 0.01ppm. If the baffle hole had 10mm radius, the loss would be 810ppm. The loss values are calculated using the formula of the  "Gaussian beam" Wikipedia article, "Power through an aperture" section. So I did not check if that one is ok.

  7480   Thu Oct 4 18:48:04 2012 janoschConfigurationPSLAOM installation

Quote:

Jenne and Jamie also find that the PMC is behaving very weird 

 Can someone detail what "weird" means? Is it singing old songs from Guns & Roses?

  7527   Thu Oct 11 11:20:05 2012 janoschUpdateGeneralbeam shape simulation, PRC

I started to create a Finesse model of the PRC cavity. We have the phase maps for the PRC and the two ITMs. I could not find anything for PR2,3 and BS. All files can be found in my SVN folder /janosch/PRC40m. I used the AutoCAD model to determine angles of incidence and distances. These numbers are largely inconsistent with numbers that you can find elsewhere on the 40m wiki, but this certainly depends on what accuracy is required for interferometer alignment and I don't understand anything about alignment.

The phase maps come in a format that needs to be modified before they can be used in Finesse. I have started with this work, but maybe someone else can take over. The phase maps show tilts and the PRC also has the curvature. These have to be subtracted out before the maps can be loaded into Finesse. I asked GariLynn for the code that they use. The Finesse model (MichPRC_40m.kat) does not load the phasemaps yet, and I just wrote some random parameter values for the TEM00 input beam to the PRC. So these Gauss parameters need to be corrected.

I will only go on with this work if Rana tells me that I should do so, otherwise it is on hold until we have a volunteer.

  7533   Thu Oct 11 21:26:40 2012 janoschUpdateGeneralPRC phase maps

Just some plots. There is nothing new here except for the fact that I learned how to analyze phase maps myself and how to prepare them for Finesse. In other words, everything is ready for a Finesse simulation.

These phase maps show the raw measurement of ITMY, ITMX and PRC:

ITM03_HR_raw.pngITM04_HR_raw.pngPRM02_HR_raw.png

Subtracting out the tilt from all phase maps, and the curvature from the PRC (I found the fit 121m consistent with previous fits), the one obtains the following residuals that can be used in Finesse (order is again ITMY, ITMX and PRC):

ITM03_HR_untilted.pngITM04_HR_untilted.pngPRM02_HR_untilted_uncurved.png

  7615   Wed Oct 24 22:48:46 2012 janoschUpdateComputer Scripts / ProgramsPhase map summary of LaserOptik mirrors

Quote:

After a long search, I've found a way to finally read and analyze(?)  the Wyko opd format data using Image SXM, an image analysis software working only on mac osx.

I am attaching the images (in tiff) and profile plot of all the 6 mirrors.

 Great, however, unless you can save the images in FITS format, we still need another reader for the opd images.

  7627   Thu Oct 25 22:52:07 2012 janoschUpdateGeneraltip-tilt phase maps

Now that I read Koji's last elog about phase maps, I am not sure if these are still required, but here they are (the tilt-removed phase maps of the Laser Optik mirrors), first 1, 2, 3:

sn1Laseroptik_untilted.pngsn2Laseroptik_untilted.pngsn3Laseroptik_untilted.png

Then 4,5,6:

sn4Laseroptik_untilted.pngsn5Laseroptik_untilted.pngsn6Laseroptik_untilted.png

So they all have an elevated center. I am not sure why the phase maps of mirrors 5 and 6 are slightly smaller in dimension. Anyhow, all mirrors have quite strong aberrations. Also, there is no big difference between the mirrors. Check for yourself, but be careful with the colors since the scales are all different.

  7629   Thu Oct 25 23:14:42 2012 janoschUpdateGeneraltip-tilt phase maps

Quote:

Are these maps drawn from the data we extracted using Image SXM??

 Indeed. So the only manipulation that I did was to remove the tilt (since this should usually be seen as an artifact of the measurement, or better, we can assume that tilt is compensated by alignment). I did not remove the curvature.

  7639   Mon Oct 29 14:57:41 2012 janoschUpdateGeneraltip-tilt phase maps

Quote:

 [Jan, Manasa]

Below are phasemaps for the tip-tilts with both tilt and RoC removed. We have not used Koji's code; but tweaked the earlier code to remove curvature. 

 The posted residual phase maps show circular contours since the data came with relatively low resolution in height. This is ok for what we want to do with these phase maps (i.e. simulating higher-order mode content in the PRC using Finesse). Better resolution is only required if you want to understand in detail optical scattering out of the cavity. Anyhow, the circular artifacts can be removed by first interpolating the phase maps to a higher lateral resolution, and then performing tilt and curvature subtraction. So we will soon have better looking phase maps posted. Then we should think about what type of Finesse simulation we could run. Certainly one simulation is to look at the beam shape in the PRC, but more interesting could be how sensitive the shape is to mirror alignments. The current simulation shows a mode that resembles the TEM01, but I have not yet tried to find optimal alignment of the mirrors (in simulation) to search for the TEM00 mode.

  7734   Tue Nov 20 16:03:37 2012 janoschUpdatePEMSeismometers and a microphone

Quote:

 I got two seismometers and one microphone back from Tara.

They are now near the Gurlap under the MC.

 If anybody wants a fancy single-axis seismometer for a while (GS-13), then please let me know.

  7319   Thu Aug 30 17:03:32 2012 janosch, Manasa, SteveUpdate ETMX

The baffle has been moved away from ETMX towards the edge of the table (in fact, it is a little beyond the edge). It is also rotated so that its long edge is horizontal. In this way it was possible to center the baffle hole with respect to the optical axis, but also make it possible that the camera looks over the baffle.

We have tried to get an alignment beam from view port -> ETMX pick-off ->ITMX-> back to EX. This work was pretty much unsuccessful though. We could see the green laser scattering around ITMX, but there was no good way to know when the beam hit ITMX. So tomorrow we will find a better way to check where the beam is hitting at ITMX and finish the alignment of the scattering pick-off mirror.

  7352   Thu Sep 6 17:11:40 2012 janosch, Manasa, SteveUpdate pick-off and baffle at ETMY

We have installed the pick-off mirror at the ETMY table for the small-angle scattering measurement on ITMY. As we had already done for the X arm pick-off, the pick-off mirror at ETMY was aligned shooting a green laser normally through the viewport on the pick-off and steering it onto ITMY.

A baffle was also installed at a distance of about 30cm from ETMY near the edge of the table.

  7317   Thu Aug 30 12:01:27 2012 janosch, Manasa,SteveUpdate ETMX

We have done some work at ETMX today. We installed the baffle and placed two mirrors on the table.

The baffle position/orientation still needs to be checked more thoroughly to make sure that the beam will pass through the center of the baffle hole.

One of the two mirrors will stay on the table as pickoff. The other is only temporarily installed for alignment purposes. Later today we will shoot a laser into the chamber that will reflect off one of these mirrors towards the center of ITMX, then go back to the pickoff mirror next to ETMX and hopefully make it through the viewport.

To place the pickoff mirror, we had to move the "cable rack" next to ETMX a few inches towards the back of the table.

  7326   Fri Aug 31 10:16:02 2012 janosch, SteveUpdate ETMX, scattering preps

The alignment of the pick-off mirror near ETMX is done. Everything turned out to be easy once we realized that there is no sense getting the alignment laser (going through viewport to pick-off to ITMX) back to ETMX. It is only necessary to hit ITMX somehow, since this makes sure that there is one scattered beam that will make it from ITMX to pick-off through viewport.

After the auxiliary optic (that we never used in the end) was removed again, we levelled the optical table.

So in the current setup, we can have small-angle scattering measurements on ITMX and large-angle scattering measurements on ETMX.

  1170   Wed Dec 3 12:49:11 2008 jenneUpdateComputerssomething sketchy with NDS ... or something
Never mind...I had forgotten that you have to run mdv_config every time you open matlab, not just every time you boot a computer.

I am not able to get channels using get_data from the mDV toolbox on Allegra, Megatron or Rosalba.

The error I get while running the "hello_world" test program is:
hello_world
setting up configuration...
added paths for nds
added paths for qscan
couldn't add path for matapps_SDE
couldn't add path for matapps_path
couldn't add path for framecache
couldn't add path for ligotools_matlab
added paths for home_pwd
fetching channels for C...
Warning: get_channel_list() failed.
??? Error using ==> NDS_GetChannels
Failed to get channel list.

Error in ==> fetch_nds at 47
eval(['CONFIG.chl.' server ' = NDS_GetChannels(ab);']);

Error in ==> get_data at 100
out = fetch_nds(channels,dtype,start_time,duration);

Error in ==> hello_world at 6
aa = get_data('C1:LSC-DARM_ERR', 'raw', gps('now - 1 hour'), 32);
  1890   Wed Aug 12 10:35:17 2009 jenneSummaryComputersNodus rebooted / SVN down

Quote:

Looks like someone rebooted nodus at ~3 PM today but did not elog it. Also the SVN is not running. Why?

 The Nodus business was me....my bad.  Nodus and the elog were both having a bad day (we couldn't ssh into nodus from op440m (which doesn't depend on the names server)), so I called Alex, and he fixed things, although I think that all he did was reboot.  I then restarted the elog per the instructions on the wiki.

 

  2069   Thu Oct 8 14:41:46 2009 jenneUpdateComputersc1susvme1 is back online

Quote:

Power cycling c1dcuepics seems to have fixed the EPICs channel problems, and c1lsc, c1asc, and c1iovme are talking again.

I burt restored c1iscepics and c1Iosepics from the snapshot at 6 am this morning.

However, c1susvme1 never came back after the last power cycle of its crate that it shared with c1susvme2.  I connected a monitor and keyboard per the reboot instructions.  I hit ctrl-x, and it proceeded to boot, however, it displays that there's a media error, PXE-E61, suggests testing the cable, and only offers an option to reboot.  From a cursory inspection of the front, the cables seem to look okay.  Also, this machine had eventually come back after the first power cycle and I'm pretty sure no cables were moved in between.

 

 I had a go at trying to bring c1susvme1 back online.  The first few times I hit the physical reset button, I saw the same error that Joe mentioned, about needing to check some cables.  I tried one round of rebooting c1sosvme, c1susvme2 and c1susvme1, with no success.  After a few iterations of jiggle cables/reset button/ctrl-x on c1susvme1, it came back.  I ran the startup.cmd script, and re-enabled the suspensions, and Mode Cleaner is now locked.  So, all systems are back online, and I'm crossing my fingers and toes that they stay that way, at least for a little while.

  2119   Mon Oct 19 17:12:54 2009 jenneUpdatePEMaccelerometers and seismomters are all good.

Quote:

Some of these channels are not like the others.

 All of the PEM channels seem to be okay right now.  The accelerometers didn't turn out to have any differences in the traces when we put both XYZ triplets right next to each other, so we put them back where they belong.  Gur2 seismometer was showing a few problems, especially with Gur2_X, as Rana posted in elog 2079.  This was solved by tightening the cable screws which hold the Dsub end of the Guralp cable to the front panel of the Guralp box.  All is now well.

  2440   Mon Dec 21 10:09:06 2009 jenneUpdateASSOAF Model update and build instructions
OAF stands for Online Adaptive Filtering. We use the same computer which was once the ASS. One of these days, we'd like to completely be rid of all things which refer to ASS, and make even the computer's name OAF.
  2685   Fri Mar 19 18:00:14 2010 jenneUpdatePEMGuralp2 centered again

[Jenne, Sanjit]

It looks like Steve used a GND-12V supply to power the Guralp through the little breakout box (the box is for checking the centering of the mass).  This is BAD.  The Guralps want +/- 12V.

We centered all of the channels on Gur2, and checked the channels on Gur1, so we'll see how they're feeling after a while.

  6750   Mon Jun 4 23:48:43 2012 jenneUpdateGreen Lockinglowered gain

We're trying to do a yarm measurement....before I forget, I want to write this down...

I changed the gain of each of the top 2 SR560's down, by a factor of 2.  This made the overload lights quit coming on.

  10812   Wed Dec 17 19:04:12 2014 jenneUpdateASCASS retuned

I made the Xarm follow the new (old) topology of Length -> test masses, and Trans -> input pointing.

It takes a really long time to converge (2+ min), since the input pointing loops actuate on the BS, which has an optical lever, which is slow.  So, everything has to be super duper slow for the input pointing to be fast relative to the test mass motion.

Also, between last night and this afternoon, I moved the green ASX stuff from a long list of ezca commands to a burt file, so turning it on is much faster now.  Also, I chose new frequencies to avoid intermodulation issues, set the lockin demodulation phases, and tuned all 4 loops.  So, now the green ASX should work for all 4 mirrors, no hand tuning required.  While I was working on it, I also removed the band pass filters, and made the low pass filters the same as we are using for the IR ASS.  The servos converge in about 30 seconds.

  7463   Tue Oct 2 15:14:54 2012 jenne, jamieUpdateIOOPZT diagnosis

pzt2 mod signals matched slider vals for both pitch and yaw

  pzt2 yaw mon output = 6
  pzt2 pitch mon output = 11.3

From the PZT connector-converter board we determined the following pin-outs:

  X=Yaw:  red=1, white=14, black=3 
  Y=Pitch:  red=2, white=15, black=16

We believe that red is signal, white/black/shield are all ground.  We also believe (although this is from the PMC PZT) that the expected capacitance of the PZTs should be in the 100's of nF range.

Here are the readings from the two PZT dsub connectors:

  pin 1:14   PZT1 = ".003" on 2uF scale
             PZT2 = ".184"
   
  pin 2:15   PZT1 = ".002" on 2uF scale
             PZT2 = ".202"

So we think this means (given this crappy capacitance meter) that PZT2 is showing roughly 200nF, which sounds ok, but that PZT1 is indeed bad.

So next we investigate the PZT2 driver.

 
  7673   Tue Nov 6 16:38:37 2012 jenne, jamie, ayaka, manasaUpdateAlignmentAlignment back under control again

We had a big alignment party early this morning, and things are back to looking good.  We have been very careful not to bump or touch tables any more than necessary.  Also, we have removed the apertures from the BS and PRM, so there are no more apertures currently left in the chambers (this is good, since we won't forget).

We started over again from the PZTs, using the PRM aperture and the freestanding aperture in front of PR2, to get the height of the beam correct.  We then moved PZTs to get the beam centered on BS, ITMY, ETMY.  We had to do a little poking of PR2 (and PR3?) to get pitch correct everywhere.

We then went to ETMX to check beam pointing, and used BS to steer the beam to the center of ETMX.  We checked that the beam was centered on ITMX.

We went through and ensured that ITMX, ITMY, PRM, SRM are all retroreflecting.  We see nice MICH fringes, and we see some fringes (although still not so nice...) when we bring PRM and SRM into alignment.

We checked the AS path (with only MICH aligned), and made sure we are centered on all of the mirrors.  This included steering a little bit on the mirrors on the OMC table, in yaw.  Initially, AS was coming out of the vacuum, but hitting the side of the black beam tube.  Now it gets nicely to the table.

For both AS and REFL, we made sure there is no clipping in the OMC chamber.

I recentered the beams for AS and REFL on their respective cameras.

IPPOS was centered on the QPD.  This involved moving the first out-of-vac steering mirror sideways a small amount, since the beam was hitting the edge of the mirror.  IPANG was aligned in-vac, and has been centered on the QPD.

Right now, Manasa, Jamie and Ayaka are doing some finishing touches work, checking that POY isn't clipping on OM2, the second steering mirror after the SRM, and they'll confirm that POX comes out of the chamber nicely, and that POP is also still coming out (by putting the green laser pointer back on that table, and making sure the green beam is co-aligned with the beam from PR2-PR3.  Also on the list is checking the vertex oplevs.  Steve and Manasa did some stuff with the ETM oplevs yesterday, but haven't had a chance to write about it yet.

  3916   Sun Nov 14 16:26:31 2010 jenne, valeraUpdateElectronicsSRM side OSEM noise with no magnet

We realized that the SRM sensors are connected to the readout but just sitting on the BS in vacuum table with no magnets and therefore no shadows in them. We swapped the inputs to the SRM and PRM satellite boxes to use the higher transimpedance gain of the PRM side sensor. The attached plot shows the current spectrum in this configuration. The PD readback voltage was 9.5 V. Since this is close to the rail we put a slightly higher voltage into the AA of this channel to test that we can read out more ADC counts to make sure we are not saturating. The margin was 15800 vs 15400 counts with p-p of 5 counts on the dataviewer 1 second trend. We returned all cables to nominal configuration.

The calibration from A to m is 59 uA/1 mm.

  12998   Thu May 18 15:20:29 2017 jigyasaSummarytelescope designTelescope Design for the Gig-E cameras

With the objective of designing a telescope system for the Gig-E, a system of two lenses is implemented. A rough schematic of the telescope system is attached. Variables in the system include the focal lengths of the two spherical lenses(f1, f2), distance between the lenses(t), distance between the test mass and the lens combination(u), distance between the other lens and the sensor(v). Also the size of the object to be desired ranges from 3’’ which is the size of the test mass to 1’’ which is approximately focusing on the beam spot implying that the required magnification ranges from 0.06089 to 0.1826 (since the sensor image circle size if ¼”)
The lenses are selected to be 2” in diameter so as to ensure sufficient collected power.

Going through the focal lengths available, namely 50, 100, 150, 200, 250 mm, and noting that the object distance would be within the ranges of 1500 to 2500 mm, plots of various accessible u and v for different values of t were obtained. This optimization was done to ensure the proper selection of the lenses. Additionally, a sensitivity analysis was performed and plots depicting the dependence of magnification on the precision limiting measurements of u (1 mm) and t (5 mm) were obtained. (These were scatter plots quantifying the deviation from the desired magnification ranges). The plots depict the error term induced on the magnification if there was an error in measuring the distance between the lenses as 5mm and if the precision in measuring the object to lens distance by 1mm.

The telescope design might be limited by spherical aberrations and coma, which might be resolved by either using aspherical lenses or by increasing the f-number (typically with an f number around 5 or 6). The use of aspherical lenses particularly parabolic lenses was considered, however this was found to be quite an expensive route. 

Analyzing the plots and taking into consideration the restrictions of the slotted lens tubes, the precision in measurement of the distances, a 150 mm- 250mm focal length solution is proposed. With a diameter of 2”, the f number is computed to be 2.95 and 4.92. With this combination and the object distances lying between 1500 to 2500 mm, the image distance to the sensor varies between 51 to 100mm. So a slotted lens tube controlling the distance between the lenses would be required.

I also considered a combination of focal lengths 250mm and 250mm, as then both of the lenses would at least have an f number of 4.92. The results for this combination are also attached. The image distance from the lens combination is about a 100 to a 140 mm. However, this would require much longer slotted length tubes thereby adding to the cost of the system. The number of accessible u-v points is the same as that for the 150-250 combination. 

I am still trying to search for a much more concrete way of quantifying aberrations.

  13000   Mon May 22 10:15:14 2017 jigyasaSummarytelescope designLens tubes and object distances

Since the f numbers of the lenses in the proposed design with biconvex lenses are a little less than 5 and the conjugate ratio(that is the ratio of object to image distance) is greater than 5, I explored the use of plano convex lenses, but with the same focal lengths, the accessible u-v range is restricted with the planoconvex rather than biconvex lenses.
On Friday, I had a discussion with Gautam and Steve about the hardware that is the cylindrical enclosures for the camera and the telescope and we examined two such aluminum cylindrical enclosures. One of them was the one being currently employed for the cameras. The dimensions were measured and the length was found to be 8’’ and an outer diameter of 26 cm within an error of 0.5 cm.
The other enclosure was longer with a length of 52 cm(±0.5 cm), outer diameter of 10”(±0.1”) and an inner diameter of 23.7cm(±0.1cm). Pictures of these enclosures are attached.
Both of these enclosures have internal optical rail to mount the camera and the telescope system. Depending on the weight of the telescope system(that includes the weight of the slotted lens tubes, the lenses), it might be more efficient to clamp the telescope system itself on the rails with the low weight camera mounted on the lens tube.
I also went around to get an idea of distance of the GigE from the test masses. This was just a step to verify if the object distances were really in the ranges being taken into consideration, that is between 1500 and 2500 mm. I also tried to cross check the measurements with the CAD drawing of the 40m. However, as I have been informed, the distances in the CAD version are not updated.

The distances from the optic to the CCD detector would range from around 75.1 cm for MC2, 94.01 cm for ITMX, 97.21 cm for ETMX, 117.19 cm for ITMY and 88.463 cm for ETMY. The illuminator for the ETMY was disconnected, so Gautam helped me access the manual lamp control to enable me to take measurements.
The values for ETMX, MC2 and ITMY are subject to an error of ±1’’. Due to a lot of obstructions, the values for ETMY and ITMX may be subject to a lot more error. Even so, these distances are clearly less than 2 meters, prompting me to run the simulations again and verify that the chosen combination is still useful.

As for the slotted lens tubes to mount the 2” lenses, the following options are available on the Thorlabs catalog. CVI and Edmunds do not seem to offer much of the stackable lens tubes.

SM2L30C is a lens tube onto which the optic can be mounted without the need of a spanner wrench. It also has a length of 3”. However, it has a rotatable slip shield which can be rotated open as and when the access to optic is required. However, there might be a slight compromise with rigidity here.

SM2L30 is a lens tube with internal thread depth of 3”, the optic can be mounted using spanner wrench and a retainer ring. The optic cannot be accessed from both ends of the tube here.
SM2M30 is a lens tube with no external threads, therefore lens tube couplers would be required to stack the tubes. The optic is accessible from both ends here though.

Considering the merits and demerits of all these available options, the use of SM2L30 might be considered as it provides a quick and efficient way of stacking multiple lens tubes. As for accessing the optic from both sides, using multiple tubes helps overcome the problem and still ensures that we are able to access a number of separation distances as per requirement.
Thorlabs also offers an internal C to external SM2 adapter so that the lens tube could be fixed onto the C mount of the camera. 

I would be examining the use of 1" diameter lenses for the eyepiece as suggested by Rana, as that might give us more flexibility. 

  13004   Mon May 22 15:01:41 2017 jigyasaUpdatetelescope designUpdated Telescope design with 1'' eye piece

I examined the use of a single lens system for the available range of focal lengths, for the required magnification and found that a focal length of at most 100 mm would be required to sufficiently cover the object distance range. This would greatly compromise with the f-number and hence lead to a lot more spherical aberrations.

Therefore, a two lens system would be more useful to implement. Using an eyepiece of 1” puts an additional constraint on the system such that the separation between the lenses must now at least equal or be greater than half the image distance from the first lens to ensure that no light from the light cone is lost. This is clarified in the schematic. The image from the first lens in absence of the second lens would form at point A, subtending an angle θ. In order to ensure that no part this light cone emerging from the first lens is lost, the second lens must be placed at a distance atleast v/2 from the first lens.

A combination of 125mm focal length 2” diameter objective with a 250 mm 1” eyepiece covers the required range of object distances (650mm to 1500 mm). Increasing the focal length of the eye piece increases the minimum object distance accessible to 700 mm. 

A glance at the accessible u, v points shows that all magnifications are not possible at a given object distance. To image the entire surface of the test mass, a distance of at least 1.25m is required from the objective, while a beam spot of 1'' diameter can be imaged easily at upto 1200 mm from the objective . This holds true even for the 150-250 mm biconvex 2" lens combination proposed earlier. 

If this sounds reasonable, we could proceed with ordering the lenses.

  13013   Thu May 25 16:42:41 2017 jigyasaUpdateComputer Scripts / ProgramsMaking pylon installation on shared directory

I have been working on interfacing with the GigE’s. I went through Joe Be’s paper and the previous elogs and verified that the code files are installed.

I then downloaded and extracted a copy of the Pylon software onto my home directory on Allegra. Gautam helped me find installation instructions on Johannes’ directory so that I could make the installation on the shared directory.

So far , according to instructions, these commands need to be executed so that the installation takes place and the rules for camera permissions are set up.

sudo tar –C /opt/rtcds/caltech/c1/scripts/GigE –xzf pylon SDK*.tar.gz

followed by ./setup-usb.sh

The Pylon viewer can then be accessed with /scripts/GigE/pylon5/bin/PylonViewerApp 

Should I go ahead with the installation in the shared directory?

  13014   Thu May 25 18:37:11 2017 jigyasaUpdateComputer Scripts / ProgramsMaking pylon installation on shared directory

Gautam helped me execute the commands mentioned above and Pylon has now been installed on the shared directory. We extracted the pylon installation from Johannes's directory to the shared drive and executing the command tar –C /opt/rtcds/caltech/c1/scripts/GigE –xzf pylon SDK*.tar.gz created an unzipped pylon5 folder in /scripts. The ./setup-usb.sh set up the udev rules for the GigE.

The installation took place without any errors.

The Pylon viewer app can now be accessed at /opt/rtcds/caltech/c1/scripts/GigE/pylon5/bin followed by ./PylonViewerApp 

Quote:

Should I go ahead with the installation in the shared directory?

 

  13020   Tue May 30 17:45:35 2017 jigyasaSummaryCamerasGigE configuration

To verify the Pylon Installation on the shared drive, I tried connecting the Basler acA640-100gm to the PoE connector and running it through Allegra.

Each time the camera was opened, I got a message on Terminal saying ‘Failed to get the node ‘AcquisitionFrameRate’ from the device’s nodemap’.

Yet, I was able to capture images in single shot and continuous shot mode. I tried to emulate the analog controls (gain at 360, Black level 121) as in Johannes’ elog  12617 and varied the exposure rate from 1 to 5 milliseconds. The camera had the Rainbow 50mm lens with which I was able to focus on some markings on the white board, however the image was extremely magnified and this lens was extremely sensitive which meant that the image went quickly out of focus.
I checked the CCD cabinet in the 40m to find 12 mm lenses which couldn’t focus properly. So I couldn’t quite get an image as Johannes had been able to obtain! I also got an image of a cable in focus but it is very dark due to the exposure time.
 WIth the components for the telescope design arriving(hopefully) by tomorrow, I should be able to assemble the telescope and capture some more images.

From Joe B’s paper and discussion with Gautam and Johannes, I came up with three models for configuring the GigE’s. Three configuration models for the GigE have been proposed which connect the camera to a computer network. While the first model is just involves connecting the camera directly to a PC with Pylon installation using a Power over Ethernet adapter, it would be only efficient in the basic IP configuration of the camera without involving a complex network. The second model describes the integration of the camera to 'Martian'. The third model combines the creation of a separate camera subnetwork and integrating this network with the main network in the lab through a switch. This model would be more efficient to employ as the number of cameras increases. The same purpose could be achieved by using a PC with two network ports one of which connects to the camera subnet while another links it to the Martian where the computers running the client script could stream desired frames.

 

  13023   Wed May 31 14:23:42 2017 jigyasaUpdateComputer Scripts / ProgramsEstablishing the EPICs channels for the GigE

To set up the EPICs channels for the GigE, Gautam and I followed the steps in the elog by him  8957 .

We copied the 11 required channels from scripts/GigE/SnapPy/example_camera.db to c1cam.db that we created, however due to conflicts with the existing CAM-AS_PORT channels, the channels could not be accessed.

We later changed the database file to Video.db and on restarting the slow machine, it was verified that the channels indeed could be written to and read from.

11 channels were added

C1: CAM-MC1_X (X centroid position)
C1: CAM-MC1_Y (Y centroid position)
C1: CAM-MC1_WX (Gaussian width in the X direction)
C1: CAM-MC1_WY (Gaussian width in the Y direction)
C1: CAM-MC1_XY (Gaussian width along XY line)
C1: CAM-MC1_SUM (Pixel sum)
C1: CAM-MC1_EXP (Exposure time in microseconds)
C1: CAM-MC1_SNAP (Control signal for taking snapshots)
C1: CAM-MC1_FILE(File name for image to saved to - time stamp automatically appended)
C1: CAM-MC1_RELOAD (Reloads configuration file)
C1: CAM-MC1_AUTO (1 means autoexposure on, 0 means autoexposure off)

The procedure followed –

  • Add the channel names to the file C0EDCU.ini (path = /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini).
  • Make a database (.db) file so that these channels are actually recorded (path = /cvs/cds/caltech/target/c1aux/Video.db).
  • Restarted the slow machine. FB
  • Verify that the channels indeed exist and can be read and written to using ezcaread and ezcawrite.

GV: Initially, I made a new directory called c1cam in /cvs/cds/caltech/target/ and made a .db file in there. However, the channels were not accessible after re-starting FB (attempting to read these channels threw up the "Channel does not exist" error). On digging a little further, I saw that there were already some "C1:CAM-AS_PORT" channels in C0EDCU.ini. The corresponding database records were defined inside /cvs/cds/caltech/target/c1aux/Video.db. So I just added the new records there. I also had to uncomment out the dummy channel in C0EDCU.ini to keep an even number of channels. Restarting FB still did not allow read/write access to the channels. Looking through the files in /cvs/cds/caltech/target/c1aux, I suspected that the epics database records are loaded when the machine is first booted up - so on a hunch I re-started c1aux by keying the crate, and this did the trick. The channels can now be read / written to (tested using Python cdsutils).

  13024   Wed May 31 18:17:28 2017 jigyasaSummaryCamerasGigE configuration

This evening I was able to obtain some images with the same lens on the GigE. 
The problem earlier, as Johannes pointed out, was that we were using too many adapters on the camera and so it was able to focus at really shallow distances or at really low depths of focus. 
So after removing the adapters we were able to focus on objects at much larger distances.

The mug for example was at a distance greater than 1.5 meters from the camera.

Here are some images that were captured on Allegra by plugging in the GigE to the PoE connector connected to the Martian. 

Quote:

I tried to emulate the analog controls (gain at 360, Black level 121) as in Johannes’ elog  12617 and varied the exposure rate from 1 to 5 milliseconds. The camera had the Rainbow 50mm lens with which I was able to focus on some markings on the white board, however the image was extremely magnified and this lens was extremely sensitive which meant that the image went quickly out of focus.

 

  13025   Wed May 31 19:18:53 2017 jigyasaSummaryCamerasGigE configuration

And here's another picture of Kaustubh, my fellow SURF, captured in all his glory by Rana! :)

 

Quote:

This evening I was able to obtain some images with the same lens on the GigE. 
The problem earlier, as Johannes pointed out, was that we were using too many adapters on the camera and so it was able to focus at really shallow distances or at really low depths of focus. 
So after removing the adapters we were able to focus on objects at much larger distances.

The mug for example was at a distance greater than 1.5 meters from the camera.

Here are some images that were captured on Allegra by plugging in the GigE to the PoE connector connected to the Martian. 

Quote:

I tried to emulate the analog controls (gain at 360, Black level 121) as in Johannes’ elog  12617 and varied the exposure rate from 1 to 5 milliseconds. The camera had the Rainbow 50mm lens with which I was able to focus on some markings on the white board, however the image was extremely magnified and this lens was extremely sensitive which meant that the image went quickly out of focus.

 

 

  13027   Thu Jun 1 15:33:39 2017 jigyasaUpdateCamerasGigE installation in the IFO area

I tried to capture some images with the GigE inside the Interferometer area in the 40m today. For that, I connected the POE injector to the Netgear Switch in 1x6 and connected it to the GigE. I then tried to access the Pylon Viewer App through Paola but that seemed to have some errors. When trying to connect to the Basler, quite a few errors were encountered in establishing connection and trying to capture the image. There were a few errors with single shot capture but the continuous shot could not even be started. To locate the problem, I tried running the Pylon installation through Allegra in the control room and everything seemed to work fine there.

Few error messages encountered

createPylondevice error :Failed to read memory at 0xc0000000, 0xd800 bytes. Timeout. No message received.
Failed to stop the camera; stopgrab: Exception Occurred: Control Channel not open


Eventually I connected Paola to the Switch with an Ethernet cable and over this wired connection, the errors were resolved and I was able to capture some images in Continuous shot mode at 103.3 fps without any problem.

In the afternoon, Steve and I tried to install the camera near MC2 and get some images of the mirrors. Due to a restricted field of view of the lens on the camera, after many efforts to focus on the optic, we were able to get this image. MC2 was unlocked so this image captures some resonating higher order mode.

With MC2 locked, I will get some images of the mirror at different exposure times and try to get an HDR image.  
As per Rana's suggestion, I am also looking up which compression format would be the best to save the images in.

 

  13029   Thu Jun 1 16:14:55 2017 jigyasaUpdateCamerasGigE installation in the IFO area

Thanks to Steve and Gautam, the IMC was locked.

I was able to capture images with the Rainbow 50 mm lens at exposure times of 100, 300, 1000, 3000, 10000 and 30 microseconds.(The pictures are in the same order). These pictures were taken at a gain of 300 and black level 64.

Special credits to Steve spent a lot of time help me a with setting up the hardware and focusing on the beam spot with the camera. 
I can't thank you enough Steve! :) 

Quote:

In the afternoon, Steve and I tried to install the camera near MC2 and get some images of the mirrors. Due to a restricted field of view of the lens on the camera, after many efforts to focus on the optic, we were able to get this image. MC2 was unlocked so this image captures some resonating higher order mode.

With MC2 locked, I will get some images of the mirror at different exposure times and try to get an HDR image.  
 

  13040   Mon Jun 5 12:27:34 2017 jigyasaUpdateCamerasAttempt to run camera server Python code

While attempting to execute the Python/Pylon code for the camera server, camera_server.py, the compiler couldn’t locate the pylon-5.0.5.so file. So I included the path for the required .so file as

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/rtcds/Caltech/c1/scripts/GigE/pylon5/lib64

So with the file linked, the python program gets executed but then shows an error self.text= gst.elementfactory_make(“textoverlay”, “text0”)
gst.ElementNotFoundError: textoverlay
 

The code reads- 

self.text= gst.elementfactory_make("textoverlay",text0")

Not sure what I am missing here. 

  13041   Mon Jun 5 12:50:42 2017 jigyasaUpdateCamerasAttempt to run camera server Python code

I think there might be a problem with the fact that the installation of the various components such as the .ini file and the Pylon software are in directories different from the ones Joe B. specifies in his paper. 

Instead of modifying the paths in the code itself, I tried creating the paths to match the code-

Update in /ligo directory 

/cds/caltech/c1/camera/L1-CAM-MC1.ini  created and then I ran the camera_server.py from scripts/GigE/SnapPy as

./camera_server.py -c /ligo/cds/caltech/c1/camera/L1-CAM-MC1.ini 

This prompted up the following on terminal- 

finished loading settings from /ligo/cds/caltech/c1/camera/L1-CAM-MC1.ini and lists the settings in the configuration file.


However the  gst.ElementNotFoundError: textoverlay still persists. 

Probably I could try putting all files in exactly the same directories as specified in the document. 

Quote:

So with the file linked, the python program gets executed but then shows an error self.text= gst.elementfactory_make(“textoverlay”, “text0”)
gst.ElementNotFoundError: textoverlay
 

The code reads- 

self.text= gst.elementfactory_make("textoverlay",text0")

Not sure what I am missing here. 

 

  13043   Mon Jun 5 18:40:12 2017 jigyasaUpdateCamerasAttempt to run camera server Python code

[Gautam, Jigyasa]

This evening, Gautam helped me resolve the error I had been encountering. I had been trying to run the code on Allegra and that threw up the gst.elementfactory_make(“textoverlay”, “text0”); gst.ElementNotFoundError: textoverlay error.
As an attempt to resolve the error, I had set up the paths to match those mentioned in the document.
However as it turns out, it wasn't really needed.

 When Gautam ran the code from Pianosa, the following error showed up
gst.elementfactory_make(“x264enc”, “ en ”);gst.ElementNotFoundError: x264.

We found that the x264 and x264enc are different entities.
Gautam then installed the Ubuntu- restricted-extras package with the following
gstreamer0.10-plugins-bad-multiverse
gstreamer0.10-plugins-ugly-multiverse

And eventually on compilation, the message ‘starting server’ was displayed on the screen. This was interrupted by another error GenICAM_3_0_Basler_pylon_v5_0::RuntimeException’

 So there is apparently a problem executing the commands on Allegra, because the camera server starts running on Donatella and Pianosa. 

I will now be looking into this newly encountered error and also be setting up the symlinks for the various paths in the code. 

Quote:

Probably I could try putting all files in exactly the same directories as specified in the document. 

Quote:

So with the file linked, the python program gets executed but then shows an error self.text= gst.elementfactory_make(“textoverlay”, “text0”)
gst.ElementNotFoundError: textoverlay
 

The code reads- 

self.text= gst.elementfactory_make("textoverlay",text0")

Not sure what I am missing here. 

 

 

  13056   Fri Jun 9 16:37:29 2017 jigyasaUpdateComputer Scripts / ProgramsOpenCV installation

OpenCV 3.1.0 has been installed by following the commands locally on Donatella

git clone https://github.com/Itseez/opencv.git
cd opencv
git checkout 3.1.0
git clone https://github.com/Itseez/opencv_contrib.git
cd opencv_contrib
git checkout 3.0.0
cd ~/opencv
mkdir release
cd release
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D OPENCV_EXTRA_MODULES_PATH=/~/opencv_contrib/modules/ ~/opencv/

In ~/opencv/release, make and sudo make install were executed.

This completed the installation. The version of the installation was verified pkg-config --modversion opencv which showed 3.1.0. Also verified the import of cv2 module in python and it seems to work fine. 

 

  13066   Thu Jun 15 18:56:31 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

A python script to randomly vary the MC2 pitch and yaw offset and correspondingly record the value of MC transmission has been started on Donatella in the control room and should run for a couple of hours overnight.

The script is named MC_TRANS_1.py and is located in my user directory at /users/jigyasa

Apologies for any inconvenience.
Data analysis will follow.

ELOG V3.1.3-