I have successfully backported the cdsRampMuxMatrix part for use in our RCG v2.5 system. This involved grabbing new files, merging changes, and hacking around missing features from RCG 2.9. 

The added/changed files, with relative paths referred to /opt/rtcds/rtscore/release/src/, are:

• M include/drv/tRamp.c
  • New C functions to directly report current ramping value and ramping state 
• M epics/util/feCodeGen.pl
  • Added if statements to main simulink parser to properly handle the part
• AM epics/util/lib/RampMuxMatrix.pm
  • New Perl script that writes the frontend code for a given ramp matrix
• A epics/util/mkrampmatrix.pl
  • New perl script that creates the default MEDM screen
• A epics/simLink/lib/cdsRampMuxMatrix.mdl
  • Simulink block for the part
• M epics/simLink/CDS_PARTS.mdl
  • Added block and doc for the part (which is missing an underscore in its definition of EPICS field names)

[A means the file was added, M means the file was modified]

Most of the trouble came from the EPICS reporting of the live ramping value and ramping state, since this depended on some future RCG value masking function. I had to rewrite the C-code writing perl script to define and update these EPICS variables in a more old-school way. 

This leaves us vunerable to the fact that a user/program can directly write to the live matrix element and ramping state, which would cause bad and unexpected behavior of the matrix.

So, when using a ramping matrix: NEVER WRITE to [MAT]_[N]_[N] as you would for a normal matrix. Use [MAT]_SETTING_[N]_[M] and trigger [MAT]_LOAD_MATRIX.

Similary, [MAT]_RAMPING_[N]_[N] is off limits. 

I tested the new part in the c1tst model. There are two EPICS input (TST-RAMP1_IN and TST-RAMP2_IN) that are the inputs to a 2x2 ramp matrix called TST-RAMP, and the outputs go to two testpoints (TST-RAMP1_OUT and TST-RAMP2_OUT) and two epics outputs (TST-RAMP1_OUTMON and TST-RAMP2_OUTMON). You can write something to the inputs from ezca or whatever, and use the C1TST_RAMP.adl medm screen in the c1tst directory to try it out. The buttons turn red when you've input a new matrix, yellow when a ramp is ongoing and green when the live value agrees with the setting. 

At this time, I have not rebuilt any of our operational models in search of potential issues.

I have created backups of the files I modified, such that a file such as feCodeGen.pl was renamed feCodeGen.40m.pl, and left next to the modified file. I am open to more robust ways of doing the backup; since our RCG source is an svn checkout of the v2.5 branch (with local modifications, to boot), I suppose we don't want to commit there. Maybe we make a 40m branch? A seperate repo? 

I have checked out the new cdsutils repository at:

/opt/rtcds/cdsutils/release

This is a new repository that is intended to hold all of our python libraries and command-line utilities for interacting with the IFO, things like:

• get/write values EPICS channels
• interact with filter module switches
• average a test point for some amount of time
• etc.

Basically everything that used to be ez* or tds*.

There's not much in there at the moment, but hopefully it will start to get filled in soon.

WARNING:

This code in here will be used by the sites to interact with the real aLIGO IFOs.  Please be careful as you develop things in here, and o so conscientiously.  If you do bad things here and it messes things up at the sites people will be angry.  Particularly me, since I have to support everything in here for Guardian use.

Usage

<cdsutils>/lib/cdsutils is the primary python library.  For each function you want to add, put it in a new file named after the function.  So for instance function "foo" should be in a file called <cdsutils>/lib/cdsutils/foo.py.

There is a command line utility at <cdsutils>/bin/cdsutils.  It will automatically find anything you add to the library and expose it as a sub command (e.g. "cdsutils foo")

We'll try to put together a wiki page describing development and usage of this soon.

We now have a proper install of cdsutils:

 controls@rossa:~ 0$ cdsutils
 usage: cdsutils <cmd> <args>

 Advanced LIGO Control Room Utilites

 Available commands:

   read         read EPICS channel value
   write        write EPICS channel value
   switch       switch buttons in standard LIGO filter module
   avg          average NDS channels for some amount of time
   servo        simple integrator (pole at zero)

 Add '-h' after individual commands for command help.
 controls@rossa:~ 0$ 

It is installed in /ligo/apps/cdsutils, and should be in the path on all workstations.

The "development" source working directory is currently checked out at /opt/rtcds/cdsutils/trunk.

 controls@rosalba:~ 0$ cdsutils
Traceback (most recent call last):
  File "/ligo/apps/cdsutils/lib/cdsutils/__main__.py", line 7, in <module>
    from cdsutils import CMDS
  File "/ligo/apps/cdsutils/lib/cdsutils/__init__.py", line 4, in <module>
    from servo import servo
  File "/ligo/apps/cdsutils/lib/cdsutils/servo.py", line 1, in <module>
    from epics import PV
ImportError: No module named epics
controls@rosalba:~ 1$ 

Mon Sep 16 19:40:32 2013 

It's in the elog already: http://nodus.ligo.caltech.edu:8080/40m/9922

But it seems like things still haven't fully recovered, or have recovered to an old state?  Why is the cdsutils install I previously did in /ligo/apps now missing?  It seems like other directories are missing as well.

There's also a user:group issue with the /home/cds mounts.  Everything in those mount points is owned nobody:nogroup.

I also can't log into pianosa and rosalba.

 I also still think it's a bad idea for everything to be mounting /home/cds from an IP address.  Just make a new DNS entry for linux1 and leave everything as it was.

 After some email consult with Jamie, I got cdsutils working again by reverting to v238. The newest versions are not compatible with our python 2.6 on Ubuntu 10. And our Ubuntu 12 machines do not have NDS2 clients that work yet.

The read/write commands work at the moment, but the NDS based ones don't yet work on pianosa due to some NDSSERVER flag/setup issue maybe, Jamie ??

controls@pianosa|~ > z

usage: cdsutils <cmd> <args>

Advanced LIGO Control Room Utilites

Available commands:

    read         read EPICS channel value

  write        write EPICS channel value

  switch       switch buttons in standard LIGO filter module

  avg          average one or more NDS channels for a specified amount of seconds

  servo        servos channel with a simple integrator (pole at zero)

  trigservo    servos channel with a simple integrator (pole at zero)

  version      print version info and exit

  help         this help

Add '-h' after individual commands for command help.

controls@pianosa|~ > z read C1:LSC-DARM_GAIN

0.0

controls@pianosa|~ 2> z avg 3 C1:IOO-MC_F

Error in write(): Connection refused

Error in write(): Connection refused

NDSSERVER variable incorrectly defined, or no NDS servers available.

controls@pianosa|~ 1> echo $NDSSERVER

fb

Should be fixed now.  There were python2.6 compatibility issues, which only show up on these old distros (e.g. ubuntu 10.04).

controls@pianosa:~ 0$ cdsutils read C1:LSC-DARM_GAIN
0.0
controls@pianosa:~ 0$ cdsutils --version
cdsutils 230
controls@pianosa:~ 0$ 

controls@pianosa:~ 0$ cd /opt/rtcds/cdsutils/trunk/
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ svn update
...
At revision 226.
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ make
echo "__version__ = '226'" >lib/cdsutils/_version.py
echo "__version__ = '226'" >lib/ezca/_version.py
...
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ make ligo-install
python ./setup.py install --prefix=/ligo/apps/linux-x86_64/cdsutils-226
...
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ ln -sfn cdsutils-226 /ligo/apps/linux-x86_64/cdsutils
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ exit
...
controls@pianosa:~ 0$ cdsutils --version
cdsutils 226
controls@pianosa:~ 0$ 

 This upgrade from Jamie has given us the new apps (avg, servo, and trigservo). We should figure out if there's a way to integrate Masayuki's work, so that we can have a 'cdsutils demod' function too.

 controls@rossa:~ 0$ cdsutils read C1:LSC-DARM_GAIN
Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/ligo/apps/cdsutils-226/lib/python2.6/site-packages/cdsutils/__main__.py", line 57, in <module>
    imp.load_module('__main__', f, pathname, description)
  File "/ligo/apps/cdsutils-226/lib/python2.6/site-packages/cdsutils/read.py", line 32, in <module>
    print ezca.Ezca(prefix).read(rest, as_string=args.as_string)
  File "/ligo/apps/linux-x86_64/cdsutils-226/lib/python2.6/site-packages/ezca/cached.py", line 17, in __call__
    key = (args, tuple(kwargs.viewitems()))
AttributeError: 'dict' object has no attribute 'viewitems'

To make the latest cdsutils available in the control room, we've done the following:

Upgrade pianosa to Ubuntu 12 (cdsutils depends on python2.7, not found in the previous release)

• Enable distribution upgrades in the Ubuntu Software Center prefs
• Check for updates in the Update Manager and click the big "Upgrade" button

Note that rossa remains on Ubuntu 10 for now.

Upgrade cdsutils to r260

• Instructions here
• cdsutils-238 was left as the default pointed to by the cdsutils symlink, for rossa's sake

Built and installed the nds2-client (a cdsutils dependency)

• Checked out the source tree from svn into /ligo/svncommon/nds2
• Built tags/nds2_client_0_10_5 (install instructions are here; build dependencies were installed by apt-get on chiara)
• ./configure --prefix=/ligo/apps/ubuntu12/nds2-client-0.10.5; make; make install
• In /ligo/apps/ubuntu12: ln -s nds2-client-0.10.5 nds2-client

nds2-client was apparently installed locally as a deb in the past, but the version in lscsoft seems broken currently (unknown symbols?). We should revisit this.

Built and installed pyepics (a cdsutils dependency)

• Download link to ~/src on chiara
• python setup.py build; python setup.py install --prefix=/ligo/apps/ubuntu12/pyepics-3.2.3
• In /ligo/apps/ubuntu12: ln -s pyepics-3.2.3 pyepics

pyepics was also installed as deb before; should revisit when Jamie gets back.

Added the gqrx ppa and installed gnuradio (dependency of the waterfall plotter)

Added a test in /ligo/apps/ligoapps-user-env.sh to load the new cdsutils only on Ubuntu 12.

The end result:

controls@chiara|~ > z
usage: cdsutils  

Advanced LIGO Control Room Utilites

Available commands:

  read         read EPICS channel value
  write        write EPICS channel value
  switch       switch buttons in standard LIGO filter module
  avg          average one or more NDS channels for a specified amount of seconds
  servo        servos channel with a simple integrator (pole at zero)
  trigservo    servos channel with a simple integrator (pole at zero)
  audio        Play channel as audio stream.
  dv           Plot time series of channels from NDS.
  water        Live waterfall plotter for LIGO data

  version      print version info and exit
  help         this help

Add '-h' after individual commands for command help.

I've checked out cdsutils-274 to /opt/rtcds/cdsutils, and updated the /ligo/apps/ligoapps-user-env.sh to have the newer machines use it by default. This was to gain access to the cdsutils.Step methods for use in the smooth ASS handoffs script. 

I clean-installed CentOS 5.5(32bit) on mafalda.
No firewalls, no SELinix.

 Yuta has removed my ethernet connection. Help me!!!

rossa:mDV>ping mafalda
PING mafalda.martian (192.168.113.23) 56(84) bytes of data.
From rossa.martian (192.168.113.215) icmp_seq=2 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=3 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=4 Destination Host Unreachable

--- mafalda.martian ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3999ms
, pipe 3

 ITMY oplev should be centered. I worked too much around it.

IOO Angle & IOO Position QPDs centered.

 Full list tomorrow: IP-Ang & Pos, ETMY-T, ETMY-Oplev, ETMX-T, IOO-Ang & Pos

 RA: No one in the control room this evening can understand what this ELOG means. Please use more words.

GOAL : To lock the central part of ifo

Here is the plan:

Mon - assemble all the cables from PDs and mixers, and check the CDS channels. Prepare the beamsplitters.

Tue - The current paths to REFL11 and REFL55 will be modified to the four paths to REFL11, 33, 55, 165. And the PDs will be placed.
Wed, Thu - during waiting for the ifo available with vacuum, help aligning the POP, POX, POY. In parallel, a simulation to find the PRC length SRC 
length tolerance will be proceeded.

Fri - When the ifo becomes available with vacuum, the sensing signals by 3-f scheme will be obtained with proper demodulation phases.

Sat - Try to lock the central part of the ifo with the new 3-f signals.

 REFL33 and REFL165 cables were connected from the AP table to the rack.  Cables on the rack for REFL33I, 33Q, 165I, 165Q ports were connected, too. Connections were confirmed by the data viewer. Two SMA cables which will be used for the two PDs on the AP tabl were built. We will be able to place the two PDs tomorrow. The beamsplitters to split the laser to REFL33 and REFL165 ports were mounted and ready to be placed.

 Almost all chamber dog clamps on the floor checked. There are a few exception where it is impossible to to get to the nut. 

Only the OOC nuts turned little bit. So our elastomer discs are holding up well. This means that the chamber anchoring to the floor is good.

 The vacuum envelope must be sealed with light doors on o-rings to insure a bug free IFO.  This was a violation!

I have changed the MC2_YAW DC bias because the PZT1_YAW was railing.

I also realigned the steering mirrors in zig-zag path since the mode cleaner tended to resonate with higher order modes after I have changed the MC2 bias.

  C1:SUS-MC2_YAW_COMM =  -1.1548    => -1.1208

Changed the list of channels to be written to frames from having the IN1 suffix to OUT. Now we can load the calibration of the channel into the filter module and the DQ channel will be calibrated.

We should do this wherever possible so that our channels will have real calibrations associated with them.
SEIS_GUR1_X_OUT 256
SEIS_GUR1_Y_OUT 256
SEIS_GUR1_Z_OUT 256
SEIS_GUR2_X_OUT 256
SEIS_GUR2_Y_OUT 256
SEIS_GUR2_Z_OUT 256
SEIS_STS_1_X_OUT 256
SEIS_STS_1_Y_OUT 256
SEIS_STS_1_Z_OUT 256
SEIS_STS_2_X_OUT 256
SEIS_STS_2_Y_OUT 256
SEIS_STS_2_Z_OUT 256
SEIS_STS_3_X_OUT 256
SEIS_STS_3_Y_OUT 256
SEIS_STS_3_Z_OUT 256
MIC_1_OUT 2048
MIC_2_OUT 2048
MIC_3_OUT 2048
MIC_4_OUT 2048
MIC_5_OUT 2048
MIC_6_OUT 2048
ACC_MC1_X_OUT 2048
ACC_MC1_Y_OUT 2048
ACC_MC1_Z_OUT 2048
ACC_MC2_X_OUT 2048
ACC_MC2_Y_OUT 2048
ACC_MC2_Z_OUT 2048
XARM_DIFFERENTIAL_MOTION_IN1 256
XARM_DIFFERENTIAL_MOTION_OUT 256
YARM_DIFFERENTIAL_MOTION_IN1 256
YARM_DIFFERENTIAL_MOTION_OUT 256

Next we should up the rate at which the model runs up to 16 kHz so that we can record the microphones at 16 kHz. FM radio has information up to 20 kHz. AM radio goes up to ~8 kHz. We should be at least as modern as AM radio. How do we make the change? How do we make sure the FOTON file stays OK?

I have made some changes to the daily summary file to compensate. New files is /users/public_html/40m-summary/share/c1_summary_page.ini.

 I've added calibration gains to Guralp (to um/sec) and EM172 (to Pa) channels.

We can run PEM at 16 kHz. I think Foton file stores both sos-representation and filter commands which are independent of the sampling frequency, so it should be possible to change model sampling frequency quickly.

In fact, we can save data at 64 kHz from iop models. I've done this once with MC_F channel. However, I did not test EM172 noise at frequencies > 1 kHz.

[Suresh, Jamie]

The new versions of these three models have been committed to the svn.  I copy below the svn log I wrote over there.

I edited three models,namely c1ioo, c1mcs and c1rfm to bring four channels from C1MCS model into the
 C1IOO model through the RFM.

We plan to use the MC2-Trans-QPD as a third sensor in addition to the WFS1 and WFS2 in the ASC system so that we can sense all the six degrees of freedom of the MC.  However the MC2-Trans_QPD is a new incarnation of the old MC2 Oplev QPD and its four segments are are picked up in the c1mcs model running on the C1SUS machine.  Since we need these    in the C1IOO machine we    had to port these signals via the RFM.  The    changes    I made to these    models are described below:
1) c1rfm.mdl -->  I added several cds parts to carry these four    channels from c1mcs to c1ioo via c1rfm

2) c1mcs.adl -->  In the MC2 block of c1mcs I cut out the structure which converts the four segments of the  QPD in the pitch, yaw and sum signals and copied it to the c1ioo model.     In the    c1mcs I  grounded the input of the oplev signals just as they are in    the MC1    and MC2    suspension blocks. I then routed the ADC channels associated with the oplev QPD signals to the rfm model.

3) c1ioo.mdl --> I have made extensive changes to the c1ioo model to include the third sensor in the WFS feedback loop.  The six lockins in the model are used to excite the MC mirrors and the signals from WFS and QPD can be demodulated to determine the input or output matrices in the WFS feedback.  A sensor_demod_array permits us to select the signals we wish to demodulate. The MCL signal, used in the MC_ASS and A2L measurements, is retained as one of the signals.  The MC_TRANS_SUM was used several in  scripts and to preserve the continuity with this channel name we inserted three EPICS parts to generate a slow channel by the same name from this model.

Since the MC_TRANS_SUM is used in the MC-autolocker script we checked to make sure that the script is running after we recompiled all the three models and restarted them.  It is all fine.

[Rana, Jenne]

While I was mostly able to restart the c1ass computer earlier today, the filter banks were acting totally weird.  They were showing input excitations when we weren't putting any, and they were showing that the outputs were all zero, even though the inputs were non-zero and the input and the output were both enabled. The solution to this ended up being to use the 2nd to last assfe.rtl backup file.  Rana made a symbolic link from assfe.rtl to the 2nd to last backup, so that the startup.cmd script does not need to be changed whenever we alter the front end code.

The startup_ass script, in /caltech/target/gds/ which, among other things, starts the awgtpman was changed to match the instructions on the wiki Computer Restart page.  We now start up the /opt/gds/awgtpman .  This may or may not be a good idea though, since we are currently not able to get channels on DTT and Dataviewer for the C1:ASS-TOP_PEM channels.  When we try to run the awgtpman that the script used to try to start ( /caltech/target/gds/bin/ ) we get a "Floating Exception". We should figure this out though, because the /opt/gds/awgtpman does not let us choose 2kHz as an option, which is the rate that the ASS_TOP stuff seems to run at.

The last fix made was to the screen snapshot buttons on the C1:ASS_TOP screen.  When the screen was made, the buttons were copied from one of the other ASS screens, so the snapshots saved on the ASS_TOP screen were of the ASS_PIT screen.  Not so helpful.  Now the update snapshot button will actually update the ASS_TOP snapshot, and we can view past ASS_TOP shots.

Foton doesn't correctly display the LSC filter bank file : C1LSC.txt.

Foton tells a lie that they all are empty.

The file itself looks fine to me i.e. I can find correct filters in text format.

Looks like someone (maybe Joe and Jenne ?) updated the file. I am not sure if this is the reason or not.

allegra:chans>ls -al | grep LSC
-rw-r--r--  1 controls controls   20659 May  5 11:46 C1LSC.txt

NEEDS TO BE FIXED SOON

 See my updated elog 4636 for what Joe and I did this morning, and what a possible problem is (making the LSC model into a sub-model).

 This was because of a bug in the RCG for foton filter module naming when top names is being used.  Rebuilding the LSC front-end model with top_names (which was needed to get around another bug in the RCG) broke the filter file.  I manually fixed the file, so it should work now.

RMS of X/Y arm length using POX/POY lock is <160 pm and <120 pm respectively. RMS of free swinging X/Y arm length is both 0.17 um.

I used ALS error signal for out-of-loop evaluation of IR lock. We can even use ALS error signal when arm is free swinging because phase tracking ALS error signal is linear to arm length.
ALS error signal might not be as good as POX/POY. So, this out-of-loop estimation might be not so good.

X arm lock using POX11:
- Openloop transfer function
   I adjusted filter (C1:LSC-XARM) gain and now, UGF ~150 Hz, phase margin ~20 deg.
  570 usec delay (number in the figure is wrong) - Edited by Yuta on July 9


- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT, calibration factor in frequency is 9.81 kHz/deg (see elog #6938), so calibration factor is 1.32 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT.
   Blue is the in-loop spectrum. Measured using C1:LSC-POX11_I_ERR, calibration factor is 3.8e12 counts/m (see elog #6841).
   Black is the expected spectrum from openloop transfer function, such as (free run)/|1+G|.



  Out-of-loop estimation of RMS during POX lock is 160 pm. But since this looks too large, ALS error signal might not see actual arm length change when arm length is locked.
  Also, it is interesting that ALS error signal sees 24 Hz peak, but POX doesn't. Roll mode coupling to green?

Y arm lock using POY11:
- Openloop transfer function
   I adjusted filter (C1:LSC-YARM) gain and now, UGF ~150 Hz, phase margin ~20 deg.
  570 usec delay (number in the figure is wrong) - Edited by Yuta on July 9


- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT, calibration factor in frequency is 9.65 kHz/deg (see elog #6938), so calibration factor is 1.30 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT.
   Blue is the in-loop spectrum. Measured using C1:LSC-POY11_I_ERR, calibration factor is 1.4e12 counts/m (see elog #6834).
   Black is the expected spectrum from openloop transferfunction, such as (free run)/|1+G|.



  Out-of-loop estimation of RMS during POY lock is 120 pm. But since this looks too large, ALS error signal might not see actual arm length change when arm length is locked.
  Also, it is interesting that ALS error signal sees 16.5 Hz peak, but POY doesn't. Bounce mode coupling to green?

Next:
  - Noise budgeting of phase tracking ALS
  - Is it possible to lock MI when RMS of arm length during POX/POY lock increased to ~100pm?

Assembled chassis from De Leone placed in the 40 Meter Lab, along the west wall and under the display pedestal table.  The leftover parts are in smaller Really Useful boxes, also on the parts pile along the west wall.

All remaining chasses have been reworked and placed on the floor along the west wall in Room 104. 

 The plot below shows how the f2p filters work.

At -2 min I turned on the f2p filters.

Suresh and I tweaked the OSEM angles in ETMX yesterday.  Last night the ETMs were left free swinging, and today I ran Rana's peakFit scripts on ETMX to check the input diagnolization:

It's well inverted, but the matrix elements are not great:

       pit       yaw       pos       side      butt
UL    0.3466    0.4685    1.6092    0.3107    1.0428
UR    0.2630   -1.5315    1.7894   -0.0706   -1.1859
LR   -1.7370   -1.5681    0.3908   -0.0964    0.9392
LL   -1.6534    0.4319    0.2106    0.2849   -0.8320
SD    1.0834   -2.6676   -0.9920    1.0000   -0.1101

The magnets are all pretty well centered in the OSEMS, and we worked at rotating the OSEMS such that the bounce mode was minimized.

Rana and Koji are working on ETMY now.  Maybe they'll come up with a better procedure.

(Kiwamu, Yuta)

Background:
  For green locking, we are planning to feedback frequency differential signal to ETM suspension for the final configuration.
  We don't have ETM suspension control system right now, so we are going to feedback the signal to X-end laser frequency for a test.
  We have two loops for the servo;
    1. coarse locking using frequency counter, feeding back to the laser temperature
    2. using VCO, feeding back to the laser PZT
  Today, we checked frequency counter SR620 and see how to get the small beat note signal(-48dBm; see elog #3771).

What we did:
  1. Using Marconi(RF signal generator), put RF signals to SR620 and see how small signal SR620 can see.
    It depends on the frequency. For 80MHz signal, you need more than about -9dBm.
       60MHz  >-12dBm
       70MHz  >-10dBm
       80MHz  >-9dBm
       90MHz  >-8dBm
      100MHz  >-7dBm

Since we are going to lock the frequency difference between X-end and PSL to 80MHz, we need at least +40dBm amp before putting the signal into SR620.

RF amplifier ZHL-32A has around +28dBm +28dB gain at 80MHz, so we need 2 of them.

  2. Marconi -> ZHL-32A -> ZHL-32A -> SR620 and see how small 80MHz signal SR620 can see.
    Around -68dBm. This should be enough.

  3. SR620 has "STRIP CHART" output on the rear panel. The output voltage is proportional to the mean frequency of the input.
    The output range is 0-8V. So in order to get 4V for 80MHz, set SCALE to 20MHz.

Plan:
 - find green beat again and see if SR620 can see it with double ZHL-32A configuration

ZHL-32A is a high power (well..., actually middle power) amplifier with the max output power of +29dBm (~1W!).
It seems to be overkill.
Your signal is so small so you don't need ZHL-32A, but can use small amp which we may have somewhere in the lab.

And the description:
"RF amplifier ZHL-32A has around +28dBm gain at 80MHz"
The unit is wrong.

Background:
  For input filter, we have analog whitening filter and also digital whitening filter. They have the same TF and when analog one is off, digital one should be on and vice versa.
  I made a python script that checks the switching automatically.

Method:
  Excite the suspension in a single frequency and see sensor inputs(XXSEN_IN1).
  Calculate the magnitude in the excitation frequency and compare it when digital whitening is off and on.
  When digital whitening is off, analog should be on, so sensor inputs should gone though the analog filter. That means the signal is multiplied by the TF of that filter, which makes the difference.

  We currently don't have excitation and I thought I have to wait, but instead of putting some extra excitation, I found that 60Hz line noise is useful.

Script:
  The script is /cvs/cds/caltech/users/yuta/scripts/WDWchecker.py
  For every sensor input, it;
    0. Stores current filter switching(XXSEN_SW1R)
    1. turns OFF the digital filter(FM1, using ezcaswitch)
    2. tdsdmd XXSEN_IN1 in 60Hz
    3. turns ON the digital filter
    4. tdsdmd XXSEN_IN1 in 60Hz
    5. divides mag(2.) by mag(4.) and calculate the analog filter gain in 60Hz
    6. Restores the filter switching in the state before the checking

Result:
  The results are;

C1:SUS-BS_ULSEN_IN1: 22.2 dB
C1:SUS-BS_URSEN_IN1: 18.7 dB
C1:SUS-BS_LRSEN_IN1: 22.7 dB
C1:SUS-BS_LLSEN_IN1: 16.0 dB
C1:SUS-BS_SDSEN_IN1: 21.5 dB
C1:SUS-ITMX_ULSEN_IN1: 16.9 dB
C1:SUS-ITMX_URSEN_IN1: 16.3 dB
C1:SUS-ITMX_LRSEN_IN1: 17.5 dB
C1:SUS-ITMX_LLSEN_IN1: 17.1 dB
C1:SUS-ITMX_SDSEN_IN1: 6.2 dB
C1:SUS-ITMY_ULSEN_IN1: 15.5 dB
C1:SUS-ITMY_URSEN_IN1: 16.5 dB
C1:SUS-ITMY_LRSEN_IN1: 17.4 dB
C1:SUS-ITMY_LLSEN_IN1: 16.3 dB
C1:SUS-ITMY_SDSEN_IN1: 18.0 dB
C1:SUS-PRM_ULSEN_IN1: 0.1 dB
C1:SUS-PRM_URSEN_IN1: 10.3 dB
C1:SUS-PRM_LRSEN_IN1: 13.1 dB
C1:SUS-PRM_LLSEN_IN1: -32.3 dB
C1:SUS-PRM_SDSEN_IN1: 14.6 dB
C1:SUS-SRM_ULSEN_IN1: 17.3 dB
C1:SUS-SRM_URSEN_IN1: 13.5 dB
C1:SUS-SRM_LRSEN_IN1: 1.6 dB
C1:SUS-SRM_LLSEN_IN1: 16.7 dB
C1:SUS-SRM_SDSEN_IN1: 18.3 dB
C1:SUS-MC1_ULSEN_IN1: 17.0 dB
C1:SUS-MC1_URSEN_IN1: 18.6 dB
C1:SUS-MC1_LRSEN_IN1: 14.9 dB
C1:SUS-MC1_LLSEN_IN1: 27.0 dB
C1:SUS-MC1_SDSEN_IN1: 16.6 dB
C1:SUS-MC2_ULSEN_IN1: 19.8 dB
C1:SUS-MC2_URSEN_IN1: 14.0 dB
C1:SUS-MC2_LRSEN_IN1: 20.8 dB
C1:SUS-MC2_LLSEN_IN1: 16.1 dB
C1:SUS-MC2_SDSEN_IN1: 17.3 dB
C1:SUS-MC3_ULSEN_IN1: 15.5 dB
C1:SUS-MC3_URSEN_IN1: 17.3 dB
C1:SUS-MC3_LRSEN_IN1: 18.2 dB
C1:SUS-MC3_LLSEN_IN1: 18.7 dB
C1:SUS-MC3_SDSEN_IN1: 16.8 dB

  Whitening filter has 18dB gain at 60Hz. (It's 3Hz pole, 30Hz zero, 100Hz zero and 0dB at DC)
  So, from the result, at least MC suspensions look like they have correct switching.
  But some channels doesn't look ok.
  We have to check those.

Plan:
   - check ITMX_SDSEN, PRM_ULSEN, PRM_LLSEN, SRM_LRSEN input filters
   - check the script and see if the script can really check. maybe the script needs some adjustments (# of averaging, multiple frequency, ......)
   - make AWG(, tdssine) work
   - check output hardware filter

By the way:
  fb is back. I don't know why. With help from Joe, I just compiled c1mcs again and again changing number of RFM channels.

Background:
 The new CDS is currently being set up.
 We want to see if the damping servo of the suspensions are working correctly.
 But before that, we have to see if the sensors and the coils are working correctly.
 Among the 8 optics, MCs take top priority because of the green beam. for the alignment of the in-vac optics.

What I did:
 By seeing the 5 sensor outputs (C1:SUS-MC1_XXSEN_IN1, XX=UL,UR,LR,LL,SD) with the Data Viewer, I checked if all the coils are kicking in the supposed direction and all the sensors are sensing that kick correctly.

 All the matrices elements were set to the ideal values(-1 or 0 or 1) this time.

Result:
 They were perfect.
1. POSITION seemed to be POSITION
 When the offset(C1:SUS-MC1_SUSPOS_OFFSET) was added, all the sensor output moved to the same direction.
2. PITCH seemed to be PITCH
 When the offset(C1:SUS-MC1_PIT_COMM) was changed, UL&UR and LL&LR went to the different direction.
3. YAW seemed to be YAW
 When the offset(C1:SUS-MC1_YAW_COMM) was changed, UL&LL and UR&LR went to the different direction.
4. SIDE seemed to be SIDE
 When the offset(C1:SUS-MC1_SDSEN_OFFSET) was added, DC level of the SD sensor output changed.

Notes:
 c1mcs crashed many times during the investigation, and I had to kill and restart it again and again.
 It seemed to be easily crashed when filters are on, and so I couldn't check whether the damping servo is working correctly or not today.

Next work:
  - fix c1mcs (and maybe others)
  - check the damping servo by comparing the displacements of each 4 degrees of freedom when servo in off and on.

Upon investigation, it appears that the c1mcs model was (and still is) timing out after a random amount of time. Or in other words, it at some point it was taking too long to do all the calculations for a single cycle and falling behind. The evidence for this is from the dmesg command when run on c1sus.

There's a bunch of lines like:

[ 8877.438002] c1mcs: cycle 568 time 62; adcWait 0; write1 0; write2 0; longest write2 0

[ 8877.438002] c1mcs: cycle 569 time 62; adcWait 0; write1 0; write2 0; longest write2 0

With a final line like: [ 8877.439003] c1mcs: ADC TIMEOUT 1 2405 37 2277

This last line indicates in fell so far behind it gave up.

However, this doesn't actually seem to be related to the amount of computation going on with the front end. I restarted the c1mcs model this morning by logging into the c1sus machine, and changing to the /opt/rtcds/caltech/c1/target/c1mcs/bin directory and running:

lsmod

sudo rmmod c1mcsfe

sudo insmod c1mcsfe.ko

The first line just lists the running modules. The second removes the c1mcs module, and the third starts it up again.

I proceeded to turn all the filters and and set all the matrix values while keeping an eye on the C1MCS-GDS_TP.adl screen and its timing indicator. It was running fine with all these turned on. Then I ran a dtt session from rosalba (going to /opt/apps/, typing bash, then source gds-env.bash, and finally diaggui) as well as a dataviewer and looked at 6 test point channels. It received data fine.

However, about 2 minutes after I had stopped doing this (although the dataviewer realtime session was still going) the USR timing jumped from about 20 microseconds to 35 microseconds, and the CPU Max timing jumped to the 50-60 microsecond range. At this point dmesg started reporting things like:

[54143.465613] c1mcs: cycle 1076 time 62; adcWait 0; write1 0; write2 0; longest write2 0

[54143.526004] c1mcs: cycle 2064 time 62; adcWait 0; write1 0; write2 0; longest write2 0

About a minute later the code gave up and reported a ADC timeout via dmesg. None of the other front ends seem to be affected.

I had to clear the test points manually after stopping dataviewer and dtt by going to rosalaba,using the sourced gds-env.bash, and running diag -l. I then typed "tp clear 36 *" to clear all the test points on the model with FEC number 36 (corresponding to c1mcs).

I removed and restarted c1mcs again, trying to turn on a few things at a time and letting it run for a few minutes to see if I could narrow down if its one particular filter perhaps reaching an underflow and starting to bog down the computations. However, after about 45 minutes of this, the model is still running and I've turned all the filters on and have been running about 8 test points with no problem, so the problem is clearly intermittent.

• Check EQ-stops
• clamp down counter weights
• check other components are clamped
• remove all tools
• check cabling is not is not shorting out seismic stack or blocking beam
• confirm well centered spots on mirrors

Summary:
  Last night, I found that some of the input channels have wrong hardware filter switching(see elog #3842).
  So, to check the whitening board(D000210), I swapped the one with ok switching and bad switching.
  During the checking, I somehow broke the board.
  I fixed it, and now the status is the same as last night (or, at least look like the same).

What I did:
  1. Switching for SRM_LRSEN looked bad and every input channel for MC3 looked OK.
     So, I unplugged the whitening board for SRM (1X5-1-5B) and plugged it into MC3's place(1X5-1-8B).

  2. Ran WDWchecker.py for MC3. The switching seemed OK for every input channel, which means the whitening board was not the wrong one.

  3. Swapped back the whitening board as it was.

  4. Found MC3_ULSEN_OUT and MC3_LLSEN_OUT was keep showing negative value(they should be positive).

  5. Check the board and found that one of LT1125 for UL/LL was wrong (broken virtual ground).

  6. Replaced LT1125 and put the board back to 1X5-1-8B.

  7. Checked the board with WDWchecker.py and dataviewer 5-hour minute trend.
      The input signal came back to normal value(Attachment #1), MC3 damping working, input filter switching seems working

Result:
  The whitening board seems OK.
  The wrong one is either wiring or RT model. Or, the checking script.

(Joe, Yuta)

Background:
 We found that the damping servo for MC suspensions somehow worked when we turned off the 13Hz Chebyshev filters.
 But that does not meet our satisfaction, so we started checking every components.
 First of all is the whitening filters.
 If we turn on a digital whitening filter(WF), corresponding analog WF should turn off, and vice versa.

Reference:
 See DCC #D000210 for the analog circuit of WF. WF has 3Hz zero, 30Hz pole, 100Hz pole. MAX333A bypasses analog WF when supplied +15V(HIGH).

What we did:
 1. Compared the transfer function between MC2_SUSPOS_EXC and MC2_ULSEN_IN1 when digital WF on and off. When digital is on/off, analog should be off/on, so there should be difference but couldn't see.

 2. We went through the simulink model and found 2 mistakes in the logic. One is the conflict with other optics. Even if we turn on/off digital WF of MC2, it didn't switched analog WF of MC2. Two is the additional bit invert (but it turned out to be our misunderstanding).

 3. We (thought we) fixed it, rebuild it, and measured the TF again.(Attachment #1)

[Attached #1]
 The red/blue line is when digital WF is on/off. Blue should be bigger(+10dB @ 10Hz according to (analog) WTF) than red, but it was the opposite.

 4. To confirm that they are doing the opposite, I checked MAX333A input(pin#1,10,11,20) in "SUS PD Whitening Board" at 1X5-1-8B (which is for MC3) and found that switching is opposite. When I turned off/on the digital WF, MAX333A input was +15V/0V. It should be 0V/+15V.

 5. Also, I found that LLSEN digital WF switch switches LRSEN analog WF and vice versa.

[Attached #2]
 Transfer functions between MC2_SUSPOS_EXC and MC2_LRSEN_IN1 with;
   Red: LR digital off, LL digital on
   Blue: LR digital off, LL digital off
   Green: LR digital on, LL digital off
 As you can see, LL switch is the one which switches LR analog WF now.

Conclusion:
 Currently, digital WF on/off corresponds to analog WF on/off.
 Also, LL/LR digital WF switch is LR/LL analog WF switch now.

Next work:
 - fix the simulink models (or wiring)
 - check dewhitening filters

Schematic:
 - whitening
   MC1 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3)
   MC2 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3)
   MC3 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3)
      D000210 has switches for bypassing analog WT(3,100:3). HIGH to bypass.
 - dewhitening
  (-) ... -> SOS Dewhitening Board(D000316) -> MC1,3 UL/UR/LR/LL coils
  (-) ... -> SOS Dewhitening Board(D000316) -> MC1,2,3 SIDE coils
  (SimDW)(InvDW) ... -> LSC Anti-imaging Board(D000186) -> Universal Dewhitening Board(D000183) -> MC2 UL/UR/LR/LL coils
     D000316 has switches for bypassing 28Hz elliptic LPF. HIGH to bypass.
     D000186 is 7570Hz elliptic LPFs.
     D000183 has switches for bypassing dewhitening filter. HIGH to bypass.
 See this wiki page for more comprehensive setup.

Our minute trends are still not available through NDS2 from the outside world due to the bad config of the DAQ, but I can confirm that we still have the minute-raw capability. This is 111 days of Seismic BLRMS.

However, it seems we're only able to get ~1 week of lookback on our second trends and that is low-down dirty shame. We used to have over a month of second trend lookback before the last decade of 'upgrades'.

fsck of chiara backup disk (UUID="90a5c98a-22fb-4685-9c17-77ed07a5e000") was done. But this required many files to be fixed. So the backed-up files are not reliable now.
On the top of that, the disk became not recognized from the machine.

I went to the disk and disconnected the USB and then the power supply, which was/is connected to the UPS.
Then they are reconnected again. This made the disk came back as /media/90a5c98a-22fb-4685-9c17-77ed07a5e000. (*)
After unmounting this disk, I ran "sudo mount -a" to follow the way of mounting as fstab does.
Now I am running the backup script manually so that we can pretend to maintain a snapshot of the day at least.

(*) This is the same situation we found at the recovery from the power shutdown. So my hypothesis is that on Oct 16 at 7 AM during the backup there was a USB failure or disk failure or something which unmounted the disk. This caused some files got damaged. Also this caused the disk mounted as /media/90a5c98a-22fb-4685-9c17-77ed07a5e000. So since then, we did not have the backup.
Update (20:00): The disk connection failed again. I think this disk is no longer reliable.

[paco, koji, tega, ian]

Today in the morning the name server / network file system running in chiara failed. This resulted in donatella/pianosa/rossa shell prompts to hang forever. It also made sitemap crash and even dropping into a bash shell and just listing files from some directory in the file system froze the computer. Remote ssh sessions on nodus also had the same symptoms.

A little after 1 pm, we started debugging this issue with help from Koji. He suggested we hook a monitor, keyboard, and mouse onto chiara as it should still work locally even if something with the NFS (network file system) failed. We did this and then we tried for a while to unmount the /dev/sdc1/ from /home/cds/ (main file system) and mount /dev/sdb1/ from /media/40mBackup (backup copy) such that they swap places. We had no trouble unmounting the backup drive, but only succeeded in unmounting the main drive with the "lazy" unmount, or running "umount -l". Running "df" we could see that the disk space was 100% used, with only ~ 1 GB of free space which may have been the cause for the issue. After swapping these disks by editing the /etc/fstab file to implement the aforementioned swapping, we rebooted chiara and we recovered the shell prompts in all workstations, sitemap, etc... due to the backup drive mounting. We then started investigating what caused the main drive to fill up that quickly, and noted that weirdly now the capacity was at 85% or about 500GB less than before (after reboot and remount), so some large file was probably dumped into chiara that froze the NFS causing the issue.

At this point we tried opening the PSL shutter to recover the IMC. The shutter would not open and we suspected the vacuum interlock was still tripped... and indeed there was an uncleared error in the VAC screen. So with Koji's guidance we walked to the c1vac near the HV station and did the following at ~ 5:13 PM -->

1. Open V4; apart from a brief pressure spike in PTP2, everything looked ok so we proceeded to
2. Open V1; P2 spiked briefly and then started to drop. Then, Koji suggested that we could
3. Close V4; but we saw P2 increasing by a factor of~ 10 in a few seconds, so we
4. Reopened V4;

We made sure that P1a (main vacuum pressure) was dropping and before continuing we decided to look back to see what the nominal vacuum state was that we should try to restore.

We are currently searching the two systems for diffrences to see if we can narrow down the culprit of the failure.

[tega, paco]

We found the files that took excess space in the chiara filesystem (see Attachment 1). They were error files from the summary pages that were ~ 50 GB in size or so located under /home/cds/caltech/users/public_html/detcharsummary/logs/. We manually removed them and then copied the rest of the summary page contents into the main file system drive (this is to preserve the information backup before it gets deleted by the cron job at the end of today) and checked carefully to identify the actual issue for why these files were as large in the first place.

We then copied the /detcharsummary directory from /media/40mBackup into /home/cds to match the two disks.

chiara local backup of /cvs/cds has not been running since the move of chiara in Nov 19. The remote backup has not been taken since 2017.
The lack of the local backup was because of the misconfiguration of /etc/fstab.

It was fixed and now the backup disk was mounted. We'll see the backup script running tomorrow morning.
The backup disk is smaller than the main disk. So sooner or later, we will face the backup problem again.

localbackup script was crying because there was no backup disk.

backup>pwd
/opt/rtcds/caltech/c1/scripts/backup
backup>tail localbackup.log
2021-12-18 07:00:02,002 INFO       Updating backup image of /cvs/cds
2021-12-18 07:00:02,002 ERROR      External drive not mounted!!!
2021-12-19 07:00:01,146 INFO       Updating backup image of /cvs/cds
2021-12-19 07:00:01,146 ERROR      External drive not mounted!!!
2021-12-20 07:00:01,255 INFO       Updating backup image of /cvs/cds
2021-12-20 07:00:01,255 ERROR      External drive not mounted!!!
2021-12-21 07:00:01,361 INFO       Updating backup image of /cvs/cds
2021-12-21 07:00:01,361 ERROR      External drive not mounted!!!
2021-12-22 07:00:01,469 INFO       Updating backup image of /cvs/cds
2021-12-22 07:00:01,470 ERROR      External drive not mounted!!!

fstab had no entry for the backup disk.

backup>cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=972db769-4020-4b74-b943-9b868c26043a /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=a3f5d977-72d7-47c9-a059-38633d16413e none            swap    sw              0       0

# OLD BACKUP DISK
#UUID="90a5c98a-22fb-4685-9c17-77ed07a5e000"    /media/40mBackup       ext4      defaults,relatime,commit=60       0         0

# CURRENT BACKUP DISK as of 2021/09/02
#UUID="1843f813-872b-44ff-9a4e-38b77976e8dc"    /media/40mBackup       ext4      defaults,relatime,commit=60       0         0

#fb:/frames      /frames nfs     ro,bg

# CURRENT MAIN DISK as of 2021/09/02
# UUID=92dc7073-bf4d-4c58-8052-63129ff5755b   /home/cds    ext4    defaults,relatime,commit=60    0   0
UUID="1843f813-872b-44ff-9a4e-38b77976e8dc"   /home/cds    ext4   defaults,relatime,commit=60    0   0

Checked the dev name of the disks and the UUIDs

backup>sudo lsblk
[sudo] password for controls:
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk
├─sda1   8:1    0 446.9G  0 part /
├─sda2   8:2    0     1K  0 part
└─sda5   8:5    0  18.9G  0 part [SWAP]
sdb      8:16   0   5.5T  0 disk
└─sdb1   8:17   0   5.5T  0 part /home/cds
sdc      8:32   0   3.7T  0 disk
└─sdc1   8:33   0   3.7T  0 part
sr0     11:0    1  1024M  0 rom
backup> sudo blkid
/dev/sda1: UUID="972db769-4020-4b74-b943-9b868c26043a" TYPE="ext4"
/dev/sda5: UUID="a3f5d977-72d7-47c9-a059-38633d16413e" TYPE="swap"
/dev/sdb1: UUID="1843f813-872b-44ff-9a4e-38b77976e8dc" TYPE="ext4"
/dev/sdc1: UUID="92dc7073-bf4d-4c58-8052-63129ff5755b" TYPE="ext4"

Added the fstab entry for the backup disk

media>cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=972db769-4020-4b74-b943-9b868c26043a /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=a3f5d977-72d7-47c9-a059-38633d16413e none            swap    sw              0       0

# OLD BACKUP DISK
#UUID="90a5c98a-22fb-4685-9c17-77ed07a5e000"    /media/40mBackup       ext4      defaults,relatime,commit=60       0         0

# OLD BACKUP DISK as of 2021/09/02
#UUID="1843f813-872b-44ff-9a4e-38b77976e8dc"    /media/40mBackup       ext4      defaults,relatime,commit=60       0         0

# Current backup disk as of 2021/12/22
UUID="92dc7073-bf4d-4c58-8052-63129ff5755b"    /media/40mBackup       ext4      defaults,relatime,commit=60       0         0

#fb:/frames      /frames nfs     ro,bg

# CURRENT MAIN DISK as of 2021/09/02
# UUID=92dc7073-bf4d-4c58-8052-63129ff5755b   /home/cds    ext4    defaults,relatime,commit=60    0   0
UUID="1843f813-872b-44ff-9a4e-38b77976e8dc"   /home/cds    ext4   defaults,relatime,commit=60    0   0