It was a bit difficult to comprehend the result.
Is it good? or bad? Have you seen the thermal effect? or not?

- Put linear lines to show the visibility of the cavity.

- Calibrate the incident power and make another plot to show the visibility (%) vs the incident power (W).

Result2:
 Attached is the visibility vs incident power(assuming output of the PD is proportional to the input laser power).
 Ideally, the graph should be flat. (In another words, attached graph in the elog #3667 shoud be linear.)
 But the visibility reduces with higher laser power in this graph. This is maybe because of the thermal effect. I'm thinking about how to confirm this.

Yesterday, a sequence of force and gain measurement was made to determine the imbalance in the

quadrant, magnetic-levitation prototype. This was the reason why it failed to achieve a stable levitation.

The configuration is shown schematically by the figure below:

Specifically, the following measurements have been made:

(1) DC force measurement among four pairs of magnets at fixed distance with current of the coils on and off

From this measurement,  the DC force between pair of magnets is determined and is around 1.6 N at with a

separation of 1 cm. This measurement also lets us know the gain from voltage to force near the working point.

The force between pair "2" is about 13% stronger than other pairs which are nearly identical. The force by the

coil is around 0.017 N per Volt (levitation of 5 g per 3 Volt); therefore, we need around 12 volt DC compensation

of pair "2" in order to counterbalance such an imbalance.  Given the resistence of the coil equal to 26 Om, this

requires almost 500 mA DC compensation. Koji suggested that we need a high-current buffer, instead of what

has been used now.

(2) DC force measurement among four pairs of magnets (with current of the coils off) as a function of distance

From this measurement, we can determine the stiffness of the system. In this case, the stiffness or the

effective spring constant is negative, and we need to compensate it by using a feedback control. This is

one of the most important parameters for designing the feedback control. The data is still in processing.

(3) Gain measurement of the OSEM from the displacement to voltage.

This measurement is a little bit tricky due to the difficulty to determine the displacement of the flag.

After several measurements, it gave approximately 2 V/cm.

Plan for the next few days:

From the those measurements, all the parameters for the plant and sensor that need to determine the

feedback control are known. They should be plugged into the simulink model and to see whether the

old design is appropriate or not. Concerning the experimental part, we will first try to levitate the configuration

with 2 pairs of magnets, instead of 4 pairs, as the first step, which is easier to control but still interesting.

- status update on LSC activity :

The measurement of the LSC sensing matrix has begun. But no useful results yet.

 The measurement script (#4850) ran pretty well after I did some modifications to adopt the script to the latest LSC model.

However the SNR weren't so great particularly in REFL33 in the PRMI configuration.

So I will tune the amplitude of excitations and integration times tomorrow.

Currently the excitation is at 238.1 Hz, where no disturbing structures are found in the spectra.

I made some attempts to measure the sensing matrix of the central part.

I could measure the matrix in the PRMI configuration but wasn't able to measure the matrix in the DRMI configuration.

   => I will report the result of the PRMI sensing matrix tomorrow.

The main reason why I couldn't lock DRMI was that the suspensions were touchy and especially the SRM suspension wasn't good.

Some impacts due to the feedback during the lock acquisition completely kicks SRM away. 

The watchdogs' RMS monitor on SRM easily rang up to more than 10 counts once the acquisition started.This is quite bad.

Also the stability of the PRMI lock was strongly depending on the gains of the PRM oplevs.

I guess I have to revisit the vertex suspensions more carefully (i.e. f2a coupling, actuator output matrix, damping gains, input matrices, oplev filters)

otherwise any LSC works in the vertex will be totally in vain.

The spot positions on ITMY and ETMY were measured using the LOCKIN modules in C1ASS when the Y arm stayed locked.

The beam was successfully aligned such that it hits the center of the ETMY mirror.

However on the other hand the angle of the beam is pitching and it's going upward as the beam propagates to ETMY.

/***** RESULTS ******/

Here is a summary of the measurement :

Also a cartoon is shown below.

The scale is not quite true, but at least it gives you a 3D information of how the beam is pointing down to the Y arm.

  /***** MEASUREMENT *****/

 In order to measure the spot positions the standard technique, namely A2L, was used.

Since the C1ASS model was made for doing the A2L measurements on each arm cavity, the LOCKIN modules in C1ASS were used.

First the Y arm was locked with AS55 (#5398), and then the C1ASS was activated by calling some scripts from C1ASS_QPDs.adl.

In order to calibrate the signals from LOCKINs, an intentional coil imbalance was introduce.

This is the same calibration technique as Valera explained before (#4355) for measurement of the MC spot positions.

Forgot to attach a picture of the ITMY's face camera when it was locked.

The horizontal position of the spot looks good, but the vertical position is apparently too low, which agrees with the A2L result.

I moved old POX shutter from ITMY optical table to the south end. MEDM POX mechanical shutter screen is now closing the green beam  injection into the Y arm.

I kluged in a 40m long bnc cable that Alberto left on the floor for control. It is labelled POX-sht  This is a temporary set up.

[Leo  w/ a little help from Kiwamu]

Leo summarized the mechanical resonances of all the suspensions, based on the free-swinging spectra taken on Sat Apr 30.

Since Leo doesn't have the wiki account I helped him putting the information on the wiki.

Good work, Leo !

http://blue.ligo-wa.caltech.edu:8000/40m/Mechanical_Resonances

"medm: command not found" error when run through command line both in pianosa and rossa in both editing and execution modes. It however gets executed and edited through the sitemap button. Don't know the source of the problem. Gautam did check the .bashrc file. aliases for SITEMAP and m40m are intact in the .bashrc file.

The workstations' .bashrc is a symbolic link to /users/controls/.bashrc

In it, someone commented out the critical line:

#source /ligo/cdscfg/workstationrc.sh

I uncommented it. medm (and all of the other things like cdsutils) work again.

I blame jamie.

 I moved the following old and obsolete MEDM directories to an archive /cvs/cds/rtcds/caltech/c1/medm

• c1vga
• c1vgl
• c1gpt
• c1gpv
• c1nio
• c1spy
• c1spx

None of these models were present in /cvs/cds/rtcds/caltech/c1/target

Remember that we don't use /cvs/cds/rtcds anymore.  Everything should be in /opt/rtcds now.

After recompiling medm with a patch for dumping screens (attached), I added a time machine to the right-click Execute menu.  It's installed under /cvs/cds/caltech/users/wipf/src/medm_time_machine. Dependencies include the python CA server module (pcaspy) and the latest nds2-client 0.11.2.  These were also installed under my users directory, to avoid interfering with other tools.

Previously, medmrun didn't accept arguments to pass along to the script it was going to run.  Jamie has graciously taken a moment from fixing the computer disaster to help me update the medmrun script.

Now the ASS scripts are call-able from the screen.

1. Gautam will get help from Johannes and finish EX table by Monday.
2. Steve will spend a day this week with Johannes on Green Monster bakeout.
3. Q to analyzed green PDH servo and design demod low pass. Should we use the double LC notches to notch the 2f product? What's the demod filter attenuation requirement?
4. Koji will make a drawing of the ruby suspension standoff prism and post into the elog so that Steve can get some quotes next week.
5. Rana to implement 40m configuration in FOGprime17 and analyze RoC matching of ETMs. Get Antonio's help to analyzed SRC stability. Maybe use PyKat and Finesse since Antonio knows that stuff.
6. Give OCXO boxes to WB refcav people. Rana get Rich to make another couple of boxes for 40m PMC, FSS, IMC.
7. Rana/Koji get EKG to make specs and procure some new folding mirrors for the PRC/SRC. Make them a bit concave and dichroic.

Last week I found that megatron was still off after the power outage. Apparently, the power recovery checklist had not been followed during the recovery.

Please remember to use the checklist and post the checklist results after each power outage. Megatron is now on and functioning.

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

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

sudo update-rc.d apache2 disable

Upgraded python on megatron. Added lines to the crontab to run autoMX.py. Edited crontab to have a PYTHONPATH so that it can run .py stuff.

But autoMX.py is still not working from inside of cron, just from command line.

[josephb, Osamu]

Megatron Setup:

To show Osamu how to setup a a front end as well as provide a test computer for Osamu's use, we used the new megatron (sunfire x4600 with 16 cores and 8 gigabytes of memory) as a front end without an IO chassis.

The steps we followed are in the wiki, here.

The new megatron's IP address is 192.168.113.209.  It is running the c1x99 front end code.

I notice that Megatron is slower than any other computer in running code that invokes optickle or looptickle (i.e. three times slower than Ottavia). Even without the graphics.

Has anyone ever experienced that?

Max and I started upgrading megatron to Ubuntu 12.NN today. We were having some troubles with getting latest python code to run to support the Summary pages stuff.

Its also a nice test to see what CDS tools fail on there, before we upgrade the workstations to Ubuntu 12.

Since its Linux, none of the usual upgrading commands worked, but after an hour or so of reading forums we were able to delete some packages and all the 3rd party packages and get the upgrade to go ahead. We'll have to re-install the LSC, GDS, LAL repos to get it back into shape and get NDS2 working. The upgrade is running in a 'screen' command on there.

Wed Oct 02 14:50:16 2013 

Update #1: The upgrade asks a couple dozen questions so it doesn't proceed by itself. I've been checking in to the 'screen' every couple hours to type in 'Yes' to let it keep going.

Update #2: It finished a few hours ago:

controls@megatron:~ 0$ uname -a
Linux megatron 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
controls@megatron:~ 0$ date
Wed Oct  2 18:33:41 PDT 2013

Kiwamu and I strung an ethernet cable from the new 1X7 rack to the 1X3 rack. The cable is labeled c1iscex-daq on both ends.  This cable will eventually connect c1iscex's second ethernet port to the daq router.  However, for today, it plugged into the primary ethernet port and is going to a linksys router.  This is the same linksys router we used to firewall megatron.

The idea is to place megatron, c1sus, and c1iscex behind the firewall to prevent any problems with the currently running while doing RFM nework tests.

The way to get into the firewalled sub-network is to ssh into megatron.  The router will forward the ssh to megatron.  Inside the network, the computers will have the following IPs.  Router is 192.168.1.1, megatron is 192.168.1.2, c1sus is 192.168.1.3, and c1iscex is 192.168.1.4.

Background:
 I measured the PMC's visibility vs incident power relation last week to see the thermal effect, but I didn't calibrated the laser power(see elog #3672).
 So, I calibrated it on Oct 12.

Setup:
 Attachment #1
 The laser grade window PW-1025-UV-1064-45P had power reflectivity of about 0.5% in this setup.

What I did:
1. Calibrated the laser power(Attachment #2).
  To measure the laser power, I put the Ophir power meter at just in front of "PMC REFL PD".

2. For the calculation of the visibility K, I used the following formula;
 K= [1-(R1-R0)/(R2-R0)]*100
where R0, R1 and R2 are the PD outputs in voltage when laser is off, PMC locked and not locked respectively.

3. Plotted the visibility vs the incident power(Attachment #3).

Result:
 Attachment #2
  From the linear fit by least squares, the calibration turned out to be 1.12±0.07 mV/uW. The error of this value is calculated from assuming PD output error~1mV and laser power error~3uW for all measured value.
  The largest error was from the position and the angle of the power meter probe.

 Attachment #3
  I used the same data I took last week(see elog #3672), but better plot.
  I put the error bars for just several points. When the laser power is weak, the errors are large because of the cancellation error. When the laser power is high, the errors are estimated to be so small that you can't see it in the plot(~1%).
  At the several points, I couldn't lock the PMC well and  the power of the reflected light depended on the offset voltage of the PZT.
  The horizontal axis has about 6% error because of the calibration error.

Note:
 Now the condition is a bit different from this measurement(NPRO temperature changed, optics moved slightly), so the visibility may be changed.

I've suspended microphones around the lab

I will do some experiments on acoustic noise canceling during my stay.
Now I am planning to cancel acoustic noise from PMC and see how the acoustic noise work and how we should place microphones.

First, I measured the noise in microphones and its circuit.

-blue, green, red, solid lines; microphone signals
-blue, green, red, dashed lines; un-coherent noise in signals
-yellow, black, solid lines; circuit noise (signal input is open, not connected to the microphones)

We can see the acoustic signal above 1 Hz, and the circuit does not seem to limit its sensitivity. But I do not know why yellow and black is so different. I will check it tomorrow.

Hi, Ayaka.  It would be good if you could give a little bit more detail about this plot:

• What exactly are the "signals"?  Are you making a sound somehow?  If so, what is producing the sound?  What is it's spectrum?
• Are the blue/green/red traces from three different microphones?
• Coherence usually implies a comparison between two signals.  Is something being compared in the dashed traces?
• Are the yellow and black traces from different amplifiers?
• What are the units of the Y axis?

 Sorry for my poor explanation.

I measured this by the same way as you measured the instrumental noise of seismometers.
I put the three microphones at the same place so that the three can hear the same sound. I did not make any sounds, just put them in the lab.
The signals from microphones are all amplified by the circuit.
And I took the correlations of each signals and two others and got the noise (dashed lines) by subtracting the correlated signal from the original signal.

So,
-The signal is the acoustic sound in the lab, amplified by the circuit.
-Three lines are from three different microphones.
-Dashed lines are subtraction of coherent signal from the original.
-Yellow and black lines are from different amplifiers in the same circuit box. The circuit has 6 channels.
-I did not calibrate the signals I got by DTT since I do not know the calibration factor now. It is just the number I got from the real time system.

Previous results
I am measuring the noise level of the microphones. The circuit does not seems to limit their sensitivities but the circuit's noise seems to be different from other channels.

Measurement
I measured the circuit noise of all 6 channels. (input open)
(mic_open.png)
The noise level is about 10 times different from the others.

Comparing the acoustic signal, microphone+circuit noise, and ADC noise;
(mic_noise.png)
- blue; acoustic signal
- green; microphone+circuit noise
- red; circuit (the data was not took simultaneously.)
- sky blue; ADC noise

To do
I will remake the circuit though the circuit does not limit the sensitivity. I would like to make sure that the circuit does not affect badly and to make the circuit noise level the same.
At the same time, I will get the PMC control signal and see coherence between it and acoustic sound.

  We have to change the sample rate and AA filter for the mic channels before going too far with the circuit design.

 To save the mic channels at higher than 2k (which we should do), we either have to move them to a different model, change the rate of the PEM model, or see if you can save data faster than the model runs (which I can't imagine is possible).

 PEM model is running at 64K now. It turned out to be tricky to increase the rate:

• BLRMS are computationally expensive and original pem model did not start at any frequency higher then 16k ( at 16k cpu meter readings were 59/60 ). Also when we go higher then 16k, front-end gives the model less resources. I guess it is assumed that this model is iop and won't need too much time. So in the end I had to delete BLRMS blocks for all channels except for GUR2Z and MIC1.
• Foton files are modified during model compilation: lines with sampling rate and declaration of filters in the beginning of the file are changed only. Sos-representation and commands are the same. I hoped that filter commands will let me change sos-representation quickly. I've opened Foton and saved the file. However, Foton modified commands in such a way that the ratio of poles and zeros to sampling rate is preserved. I guess all filters have to be replaced or this process should be done in another way.
• BLRMS block uses low-pass filters below 0.01 Hz, increasing the sampling rate by a factor of 32 might make calculations incorrect. I'll check it.

We should also increase cut off frequency of the low-pass filter in the microphone pre-amplifier from 2 kHz up to ~20-30 kHz.

 Thank you for changing the sample rate!
Also we have to change the Anti-Aliasing filter, as Jamie said.

Now my question is, whether S/N ratio is enough at high frequencies or not. The quality of EM172 microphone is good according to the data sheet. But as you can see in previous picture, the S/N ratio around 1kHz is not so good, though we can see some peaks, e.g. the sound that a fan will make. I have to check it later.
And, is it possible to do online adaptive noise cancellation with a high sampling rate such that computationally expensive algorithms cannot be run?

  That's no good - we need BLRMS channels for many PEM channels, not just two. And the channel names should have the same name as they had in the past so that we can look at long term BLRMS trends.

I suggest:

1. Have a separate model for Mics and Magnetometers. This model should run at 32 kHz and not have low frequency poles and zeros. Still would have acoustic frequency BLRMS.
2. Have a low frequency (f_sample = 2 kHz) model for seis an acc. Seismometers run out of poop by 100 Hz, but we want to have the ACC signal up to 800 Hz since we do have optical mount resonances up to there.
3. Never remove or rename the BLRMS channels - this makes it too hard to keep long term trends.
4. Do a simple noise analysis to make sure we are matching the noise of the preamps to the noise / range of the ADCs.
5. Immediately stop using bench supplies for the power. Use ONLY fused, power lines from the 1U rack supplies.

Ayaka, Den

 C1PEM model is back to 2K.

We created a new C1MIC model for microphones that will run at 32K. C1SUS machine is full, we have to think about rearrangement.

For now, we created DQ channels for microphones inside iop model, so we can subtract noise offline.

We provided 0-25 kHz bandwidth noise to AA board and saw the same signal in the output of ADC in the corresponding channel. So cut-off frequency is higher then 25 kHz. There is a label on the AA board that all filters are removed. What does this mean?

We've turned off AA bench power supply, prepare to use fused from 1U.

Tonight I wanted to measure the ambient noise level using Blue Bird mics and figure out if Panasonic WM61a or Primo EM172/173 will be good enough or not. Blue Bird that is in the control room does not seem to work. May be the problem is with the pre-amplifier. The output measured by ADC/Oscilloscope is noise ( amplitude=5mV ). I will return to this issue tomorrow.

I've installed Blue Bird microphone to listen to the acoustic noise at the PSL near PMC.

Coherence between MC_F and Blue Bird output (C1:PEM-ACC_MC2_Z for now) is changing from low to high value at frequencies 20 - 200 Hz with period ~1 min. Maybe HEPA works with some periodicity. Now it works pretty hard, ~80% of max.

I've soldered EM172 microphones to BNC connectors to get data from them.

Then I've build an amplifier for them. The circuit is

I've build 6 such circuits inside 1 box. It needs +15 V to A3 and GND to A2. A1 power channel is not used.

LISO model for this scheme was created and simulation results were compared to measurement of each channel

Measured noise curve (green) is the SR785 own noise.

Last night Rana noticed that the overflows on the ITM and ETM coils were a crazy huge number.  Today I rebooted c1dcuepics, c1iovme, c1sosvme, c1susvme1 and c1susvme2 (in that order).  Rob helped me burt restore losepics and iscepics, which needs to be done whenever you reboot the epics computer.

Unfortunately this didn't help the overflow problem at all.  I don't know what to do about that.

Just start by re-setting them to zero.  Then you have to figure out what's causing them to saturate by watching time series and looking at spectra.

As usual, we noticed the frame builder wasn't connecting happily with the rest of the computers just as we were about to lock some stuff (we never notice it being bad when we're not trying to use the frame builder....)

All the big rectangles by each computer were white.  I restarted daqd, and that brought most things back.  c1lsc and c1sus needed their mx_streams restarted manually to get everything green again.

I've had about enough whine with my computers for tonight.

 I'm starting to feel like a wine-o here.  Yuta wanted to glance at the PRM oplev dataviewer, and lo and behold, the fb lost connection just as he decided to do that.  We had checked the front end status screen not 1 minute beforehand, and everything was green.  Lame.

Did we turn off minute trend writing in one of the recent FrameBuilder debug sessions? Seems we only have second trends in 2016. Maybe this explains why its so slow to get minute trends? Dataviewer has to rebuild it from second trend.

controls@nodus|frames > l
total 64
drwx------   2 root     root     16384 Jun  8  2009 lost+found/
drwxr-xr-x   2 controls controls  4096 Jul 14  2015 tmp/
-rw-r--r--   1 controls controls     0 Jul 14  2015 test-file
drwxr-xr-x   5 controls controls  4096 Apr  7  2016 trend/
drwxr-xr-x   4 root     root      4096 Apr 11  2016 archive/
drwxr-xr-x 789 controls controls 36864 Jan 13 19:34 full/
controls@nodus|frames > cd trend
controls@nodus|trend > l
total 3340
drwxr-xr-x 258 controls controls 3342336 Jul  6  2015 minute_raw/
drwxr-xr-x 387 controls controls   36864 Nov  5  2015 minute/
drwxr-xr-x 969 controls controls   36864 Jan 13 19:49 second/

Yes, writing minute trends causes hourly FB crashes in the current state of things. The "raw" minute trending is turned on, but I think that these are unknown to nds.