A    c1/lsc/help/C1LSC_LA_SET.txt
svn: In directory 'c1/lsc/help'
svn: Can't copy 'c1/lsc/help/.svn/tmp/text-base/C1LSC_RFadjust.txt.svn-base' to 'c1/lsc/help/.svn/tmp/C1LSC_RFadjust.txt.tmp.tmp': No such file or directory

I found a strange jump of value in my data taken with tdsdata.
I couldn't find same jump in a playback of DataViewer, so I think this is a problem of tdsdata.
Be careful when you use tdsdata!

The attached file is an example of jumped data.
I try to get data with allegra and op440m, and both has same kind of jump.
(A downsampling or interpolation may be wrong.)

Rana said there is a fixed version of tdsdata in some PC, but 64bit linux may not have.
I try it tomorrow.

 Both the Upgrade and the Old40m's signals look anomalous since the zero-crossing point does not change with the demodulation phases.

I suspect there's is a problem with the optickle model of the 40m.

Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.

He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.

This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:

./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt

I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only

associated with testpoints and so we have to wait for the TP fix.

I tested new tdsdata and found it was working well.

I excited C1:SUS-ITMY_SUSPIT_EXC with tdssine, and get data from C1:LSC-TRY_OUT (testpoint) and C1:SUS- ITMY_OPLEV_PERROR (recorded point) with new and old tdsdata.

With old tdsdata (/cvs/cds/caltech/apps/linux/tds/bin/tdsdata), I found some jumps of datapoint, which is a same problem with before (Attachment 1).

With new tdsdata (/cvs/cds/caltech/apps/linux/tds_090304/bin/tdsdata), there looks to be no jumps (Attachment 2; taken about 10 minutes after Attachment 1).

The problem of old tdsdata looks to be remaining even for recordedpoints.

You should use /cvs/cds/caltech/apps/linux/tds_090304/bin/tdsdata.

We confirmed that new tds(/cvs/cds/caltech/apps/linux/tds_090304/) works well on linux 64, and replaced it to /cvs/cds/caltech/apps/linux/tds/

The old /cvs/cds/caltech/apps/linux/tds is put in /cvs/cds/caltech/apps/linux/tds.bak

 The tdscntr.pl in the new tds was probably the one from LLO, which is actually the version I sent to Tobin. It had paths and channel names defined for the LLO. So I copied back my original 40m version.

The ndsproxy tcl task on nodus was eating up all the CPU and making the elog slow. I killed it and restarted it.

It looks like it hasn't been making a log file since January. Someone who has some skill in decoding the cryptic csh stdout redirection

syntax should look into this (its in target/ndsproxy/)

I edited the configure scripts (those called from the C1IFO_CONFIGURE screen) for restore XARM and YARM.  These used to misalign the ITM of the unused arm, which is totally unnecessary here, as we have both POX and POY.  They also used to turn off the drive to the unused ETM.  I've commented out these lines, so now running the two restores in series will leave a state where both arms can be locked.  This also means that the ITMs will never be deliberately mis-aligned by the restore scripts.

I added op540m's display 0 (the northern-most monitor in the control room) to the MEDM screens webpage: https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

Now we can see the StripTool displays that are usually parked on that screen.

I started two scripts, senseDRM and loadDRMImatrixData.m, which Peter will bang on until they're correct.  They're in the $SCRIPTS/LSC directory.  The first is a perl script which uses TDS tools to drive the DRM optics and measure the response at the double demod photo-detectors, and write these results to a series of files loadable by matlab.  The second loads the output from the first script, inverts the resulting sensing matrix to get an input matrix, and spits out a tdswrite command which can be copied and pasted into a terminal to load the new input matrix values. 

What's left is mainly in figuring out how to do the matrix inversion properly.  Right now the script does not account for the output matrix, the gains in the feedback filters at the measurement frequency, or the fact that we'll likely want the UGF of our loops to be less than the measurement frequency.  Peter's going to hash out these details.

I am attempting to use the DTT program to look at the coherence of the individual accelerometer signals with the MC_L signal. Rana suggested that I might break up the XYZ configuration, so i wanted to see how the coherence changed when I moved things around over the past couple of weeks, but I keep getting a synchronization error every time I try to set the start time to more than about 3 days ago. I tried restarting the program and checking the "reconnect" option in the "Input" tab, neither of which made any kind of difference. I can access this data with no problem from the Data Viewer and the Matlab scripts, so I'm not really sure what is happening. Help?

EDIT: Problem solved - Full data was not stored for the time I needed to access it for DTT.

I ran the start Apache script as described by Yoichi in the WIki. SVN back up.

Lately I've been trying to sort out the problem of the discrepancy that I noticed between the values read on the spectrum analyzer's display and what we get with the GPIB interface.

It turns out that the discrepancy originates from the two data vector that the display and the GPIB interface acquire. Whereas the display shows data in "RAW" format, the GPIB interface, for the way the netgpibdata script is written, acquires the so called "error-corrected data". That is the GPIB downloaded data is postprocessed and corrected for some internal calibration factors of the instrument.

 I noticed that someone, that wasn't me, has edited the wiki page about the netgpibdata under my name saying:

 " [...]

* A4395 Spectrum Units
Independetly by which unites are displayed by the A4395 spectrum analyzer on the screen, the data is saved in Watts/rtHz"

 The elog crashed when I was uploading a photo just now. I logged into nodus and restarted it.

I've installed COMSOL 4.0 for 32/64 bit Linux in /cvs/cds/caltech/apps/linux64/COMSOL40/

It seems to work, sort of.

Notes:

1. It did NOT work according to the instructions. The CentOS automount had mounted /dev/scd0 on /media/COMSOL40. In this configuration, I was getting a permission denied error when trying to run the default setup script. I did a 'sudo umount /dev/scd0' to get rid of this bad mount and then remounted using 'sudo mount /dev/dvd /mnt'. After doing this, I ran the setup script '/mnt/setup' and got the GUI which started installing as usual.
2. I also pointed it at the linux64/matlab/ installation.
3. It seems to not work right on Rosalba because of my previous java episode. The x-forwarding from megatron also fails. It does work on allegra, however.

I placed a script for killing all instances of the dataviewer program on the current computer in /cvs/cds/caltech/scripts/general/.  Its called killdataviewer.  This is intended to get rid of a bunch of zombie dataviewer processes quickly.  These processes get into this bad state when the dataviewer program is closed in any way other than the graphical menu File -> Exit option.

Its contents are very simple:

#/bin/bash

kill `ps -ef | grep dataviewer | grep -v grep | grep -v killdataviewer | awk '{print $2}'`

Someone had left a typo in the MC autolocker script recently while trying to set the lock threshold to 0.09. As a result, the autlocker wouldn't run.

I repaired it, made a few readability improvements, and checked in the new version to the SVN. If you make script changes, check them in. If you think its too minor of a change for a SVN checkin, don't do it at all.

I made some changes to the elog on nodus:

• Made a backup of /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg called elogd.cfg.bk.20100407 in the same directory
• Added a folder: /cvs/cds/caltech/elog/elog-2.7.5/logbooks/EAGER_Lab
• Restarted the elog daemon via the start-elog-nodus script in the elog-2.7.5 directory

I saw that the current version of the elog seems to be in the svn, so tried to svn the changes from nodus via ssh, but got this message:

"svn: This client is too old to work with working copy '/cvs/cds/caltech/elog/elog-2.7.5'; please get a newer Subversion client."

I feel I should svn this but don't want to *&#@ the svn/elog up.

For now I will leave it alone and ask a question: Is the folder /cvs/cds/caltech/elog/elog-2.7.5/ under SVN control? Is it also under CVS control?

TL;DR:  New tab added to elog.

I've wheeled the old HP audio frequency signal analyzer into the control room to debug the GPIB/python interface. The wireless setup was getting more than 80% packet loss in the office area.

I also noticed that we have multiple and competing copies of the netgpib package installed. Kiwamu is going to merge them soon. Pleae only use the official location:

scripts/general/netgpibdata/

which is also the SVN working copy. Committ all changes periodicallty so that we can share the updated versions between sites.

Joe and I were looking at the RCG VCO algorithm to determine if we could adapt it to run at a faster rate (you can currently change its frequency at 1Hz). I noticed that the algorithm that is used to calculated the values of sine and cosine at time T1  is a truncated Taylor series which uses the values of sine and cosine calculated at time T1 - Delta t . I was concerned that there would be an accumulating phase error so I tested the algorithm in MATLAB and compared it to a proper calculation of sine and cosine. It turns out that at a given 'requested' frequency there is a constantly accumulating phase error - which means that the 'actual' frequency of the RCG VCO is incorrect. So I have plotted the frequency error vs requested VCO frequency. It gets pretty bad!

 Here's the code I used:

dt = 1/16384;

diffList = [];
% set the frequencies
flist = 1:5:8192;
for f = flist;
   
    % get the 'accurate' values of sine and cosine
    tmax = 0.05;
    time1 = dt:dt:tmax;
    sineT = sin(2.0*pi*f*time1);
    cosineT = cos(2.0*pi*f*time1);
   
    % determine the phase change per cycle
    dphi = f*dt*2*pi;
    cosT1 = 1:numel(time1);
    sinT1 = 0*(1:numel(time1));
   
    % use the RCG VCO algorithm to determine the values of sine and cosine
    for ii = 1:numel(time1) - 1;                 
        cosNew = cosT1(ii)*(1 - 0.5*dphi^2) ...
                      - (dphi)*sinT1(ii);
        sinNew = sinT1(ii)*(1 - 0.5*dphi^2) ...
                      + (dphi)*cosT1(ii);
                 
       
        cosT1(ii+1) = [ cosNew];
        sinT1(ii+1) = [ sinNew];
       
    end
    % extract the phase from the VCO values of sine and cosine
    phaseT = unwrap(angle(cosineT + i* sineT));
    phaseT1 = unwrap(angle((cosT1 + i*sinT1)));
   
    % determine the phase error for 1 cycle
    diff = phaseT1 - phaseT;
    % determine the frequency error
    slope = (diff(2) - diff(1))/(dt);
   
    diffList = [diffList, slope];
    disp(f)
    pause(0.001)
end

% plot the results
close all
figure
orient landscape
loglog(flist, abs(diffList/(2.0*pi)))
xlabel('Requested VCO Frequency (Hz)')
ylabel('Frequency error (Hz)')
grid on

print('-dpdf', '/users/abrooks/VCO_error.pdf')


I added an alias to the sitemap MEDM screen in /cvs/cds/caltech/target/cshrc.40m

Now you can enjoy launching sitemap from a terminal.

alias sitemap 'medm -x /cvs/cds/rtcds/caltech/c1/medm/sitemap.adl'

I thought that "m40m" was the traditional alias for the sitemap...

rossa:~>alias
...

m40m ${medm_base} ${medm_newtail} &
...
sitemap medm -x /cvs/cds/rtcds/caltech/c1/medm/sitemap.adl

rossa:~>set|grep medm
medm_base       medm
medm_newtail    -x /opt/rtcds/caltech/c1/medm/sitemap.adl
medm_tail       -x /cvs/cds/caltech/medm/sitemap.adl

I have made a python script to generate the button designed by Jeff Kissel for his ISI screen.

It is currently located at the following location:
/cvs/cds/rtcds/caltech/c1/medm/c1lsc_tst/master/KisselButtonGenerator/generate_KisselButton.py
but should be relocated to somewhere appropriate.
It also uses fragmented medm files named "MATRIX*.adl_parts".

# Jamie, could you suggest the right place?

The parameters are assigned at the beggining of the script.
This script print the result to stdout. So you need to redirect the output into a file.
e.g.
> ./generate_KisselButton.py >tmp.adl


The script should be modified such that it accepts the command line options.
It needs more python learning for me.

# Number of the column
mat_h = 20;

# Number of the row
mat_v = 10;

# horizontal pixel size of the rectangular display for each matrix element
button_width = 8;

# vertical pixel size of the rectangular display for each matrix element
button_height = 8;

replace_dict = {
# Title
    '${DISPLAY_LABEL}':'ITMX_INMATRIX', 
# Path of the MEDM file to be open by clicking the button
    '${DISPLAY_NAME}':'/cvs/cds/rtcds/caltech/c1/medm/c1sus/master/C1SUS_ITMX_INMATRI
X_MASTER.adl',
# The channel name of the matrix element
# ($V and $H are replaced to the numbers i.e. "_3_4")
    '${MATRIX_CHAN}':'C1:SUS-ITMX_INMATRIX_$V_$H'
    };