ELOG 40m

MC PDH lock : readjustment of demodulation phase

IOO

Since Suresh has installed the RF source box and changed the cable configuration somewhat,

the demodulation phase for the MC locking became off by about 10 degree.

I changed the length of some cables and obtained a good demodulation phase by the same technique as Suresh and Koji did before (see here for detail).

I maximized the Q signal. The lock of the MC looks healthy.

Quote from #4578

RF Source box has been mounted in the 1X2 rack.

4581

Thu Apr 28 12:25:11 2011

Further adventures in Hyper-threading

First, I disabled front end starts on boot up, and brought c1sus up. I rebuilt the models for the c1sus computer so they had a new specific_cpu numbers, making the assumption that 0-1 were one real core, 2-3 were another, etc.

Then I ran the startc1SYS scripts one by one to bring up the models. Upon just loading the c1x02 on "core 2" (the IOP), I saw it fluctuate from about 5 to 12. After bringing up c1sus on "core 3", I saw the IOP settle down to about 7 consistently. Prior to hyper-threading it was generally 5.

Unfortunately, the c1sus model was between 60 and 70 microseconds, and was producing error messages a few times a second

[ 1052.876368] c1sus: cycle 14432 time 65; adcWait 0; write1 0; write2 0; longest write2 0 [ 1052.936698] c1sus: cycle 15421 time 74; adcWait 0; write1 0; write2 0; longest write2 0

Bringing up the rest of the models (c1mcs on 4, c1rfm on 5, and c1pem on 6), saw c1mcs occasionally jumping above the 60 microsecond line, perhaps once a minute. It was generally hovering around 45 microseconds. Prior to hyper-threading it was around 25-28 microseconds.

c1rfm was rock solid at 38, which it was prior to hyper-threading. This is most likely due to the fact it has almost no calculation and only RFM reads slowing it down.

c1pem continued to use negligible time, 3 microseconds out of its 480.

I tried moving c1sus to core 8 from core 3, which seemed to bring it to the 58 to 65 microsecond range, with long cycles every few seconds.

I built 5 dummy models (dua on 7, dub on 9, duc on 10, dud on 11, due on 1) to ensure that each virtual core had a model on it, to see if it helped with stabilizing things. The models were basically copies of the c1pem model.

Interestingly, c1mcs seemed to get somewhat better and only taking to 30-32 microseconds, although still not as good as its pre-hyper-threading 25-28. Over the course of several minutes it was no longer having a long cycle.

c1sus got worse again, and was running long cycles 4-5 times a second.

At this point, without surgery on which models are controlling which optics (i.e. splitting the c1sus model up) I am not able to have hyper-threading on and have things working. I am proceeding to revert the control models and c1sus computer to the hyper-threading state.

4580

Thu Apr 28 10:53:50 2011

Adventures in Hyper-threading

What was done:

1) Turn off MC1, MC2, MC3, BS, ITMX, ITMY, PRM, SRM watchdogs.

2) Turn c1sus computer off (sudo shutdown now)

3) Go connect monitor and keyboard to c1sus. Turn c1sus on.

4) Hit "del" key at the right time to go to setup (BIOS).

5) Go to BIOS advanced tab, CPU options, enable Multi-threading.

6) Hit F10 to save and let the computer continue booting.

What went wrong:

Once c1sus was up, I noticed several red lights and dead keep alives for the c1sus models.

Typing dmesg on c1sus revealed many messages like:

[ 107.583420] c1x02: cycle 33737 time 20; adcWait 10; write1 0; write2 0; longest write2 0 [ 107.583771] c1x02: cycle 33760 time 19; adcWait 11; write1 0; write2 0; longest write2 0

This indicates the Input/Output Processor (IOP) is not completing its duties within the 15 microseconds (1/64 kHz) that it has. These lines indicate its take 20 or 19 microseconds. (I saw messages ranging from 16 to 22 microseconds).

So this seems to agree with Rolf's observations that hyperthreading can cause a 5-10 microsecond increase in computation time.

So the next thing to do is modify which core the codes are running on, and try to get them paired up on the same physical core.

4579

Thu Apr 28 07:14:34 2011

Suresh

RF Distribution box installed

RF Distribution box has been mounted in the 1Y2 rack and is ready for use.

The box receives 11 and 55 MHz Demod Signals from the RF source located in the 1X2 rack.

4578

Thu Apr 28 06:46:30 2011

RF Source box has been mounted in the 1X2 rack.

Heliax cables have been directly attached to the box and anchored on the side of the 1X2 rack. Here is a list of Helix cables which have been connected so far.

Cables	old name	New name	From -> To
1	133 MHz	11 Mhz Demod	1X2 to 1Y2 rack
2	199 MHz	55 MHz Demod	1X2 to 1Y2 rack
3	166 EOM	11 MHz EOM	1X2 to PSL table
4	33 EOM	55 MHz EOM	1X2 to PSL table
5	REFL 33	AS11	AS table to 1Y2

4577

Wed Apr 27 21:19:25 2011

Restarted with script ...

LSC whitening for PD1-4

On the back side of 1Y2 rack I found a cable, CAB-1X2-LSC_7, which is supposed to be connected to the whitening filter was disconnected.

I plugged it back and confirmed that the whitening filter is under control of EPICS.

Now all the gain sliders seem to be working because I can change the amplitude of signals with the sliders.

(method)

To check if the gain sliders are working or not, I intentionally disconnected all the inputs to the whitening filter.

Then I brought a gain slider of interest to the maximum. Due to the big gain I was easily able to see noise lying above ADC noise.

Also if the gain slider is 0 dB, which is the minimum value, the spectrum becomes just ADC noise.

In this way I checked all the gain sliders from PD1 to PD4. The picture below is just an example screenshot when I was doing this test.

Note that each filer is designed to have two poles at 150 Hz and two zeros at 15 Hz.

Quote from #4570

While checking whitening filters on the LSC rack, I found some epics controls for the whitening looked not working.

So I powered two crates off : the top one and the bottom one on 1Y3 rack.

These crates contain c1iscaux and c1iscaux2. Then powered them on. But it didn't solve the issue.

4576

Wed Apr 27 21:08:08 2011

I worked on AS_11 today. Its ready for its noise / optical gain calibrations. I have left it on Suresh's desk.

This was one of the 24.5 MHz Black Box (Ben Abbott) style RFPDs rescued from LLO. The tunable inductor that was installed was too small to get the frequency down to 11 MHz and so I swapped in one of the shielded, ferrite core ones from our '7mm' CoilCraft kit. It had a range of 1.2 - 1.8 uH according to the datasheet.

I wasn't able to simulataneously get the peak at 11.06 MHz and the notch at 59.3 MHz and so I took Koji's advice and tuned the peak best. The plot above shows how the notch is slightly off. I think its not a problem; to get it better we would have to change out the inductor for the "2-omega" notch, but I was too lazy. The thinking is that its more important to have the gain be symmetric around the signal readout frequency so as to not imbalance the audio sidebands.

Since this one is going to be AS_11, we think that the 22 MHz signal will be tiny: the transmission of the 11 MHz sidebands to the dark port is small. If we later want to put in a 22 MHz notch anyway, there is space to do this via the 'active notch' pads around the MAX4107.

For the above plot, I used the Jenne laser. The DC output of the PD was ~30 mV (~0.6 mA). The RF drive to the laser was -10 dBm: no saturations. I have calibrated out the cable responses, but not using the 1811 setup, so the absolute calibration has yet to be done.

Also, it needs some new stickers. It would be handy if someone can figure out how to get some sheets of stickers that we can put into the printer. Then we can laser printer all of the data onto the stickers and stick them to the RFPD box.

4575

Wed Apr 27 20:14:16 2011

Aidan

Summary

elog

4574

Wed Apr 27 18:14:48 2011

preparation for DRMI locking : RF status

POX11 (see this entry) is now listed as REFL11 (on the very top row).

We will rename POY11 to POP11 for DRMI locking.

The files are on https://nodus.ligo.caltech.edu:30889/svn/trunk/suresh/40m_RF_upgrade/.

4573

Wed Apr 27 17:38:01 2011

Re : AS55 demod board with new 90 deg splitter : healthy

Electronics

Figure.1 I-Q relative phase measurement as a function of LO power.

Blue curve : relative phase of AS55 that I have modified today (#4572).

Red curve : relative phase of AS11 that I had modified a week ago (#4554). Just for comparison.

The relative phase of AS55 agrees approximately what we expected according to the datasheet of PSCQ-2-51W. We expected 85 degree.

Figure.1 I-Q amplitude imbalance as a function of LO power.

From - 5 dBm to 5 dBm in LO power the imbalance is within 3 %.

But the precision of the measurement is also about 2 % (because I used an oscilloscope). Even so the imbalance is still good.

Quote from #4572

Some plots will be posted later.

4572

Wed Apr 27 15:34:38 2011

AS55 demod board with new 90 deg splitter : healthy

Electronics

A new 90 deg splitter, PSCQ-2-51W, has been installed on another demod board called AS55.

It shows a reasonably close 90 degree separation between the I and Q signals at 55 MHz with various LO and RF power.

So far we have ordered only three PSCQ-2-51Ws for test. Now we will order some more for the other demodulators.

Some plots will be posted later.

4571

Tue Apr 26 22:56:35 2011

with script

Tue Apr 26 22:56:01 2011

c1iscaux2 and c1iscaux restrated

While checking whitening filters on the LSC rack, I found some epics controls for the whitening looked not working.

So I powered two crates off : the top one and the bottom one on 1Y3 rack.

These crates contain c1iscaux and c1iscaux2. Then powered them on. But it didn't solve the issue.

4569

Tue Apr 26 22:03:49 2011

I used the Jenne AM laser to tune up the PD (used to be POX_11 but now is called REFL_11). In addition to the notch at 22 MHz, I have also put in a LC notch at 5*f = 55.3 MHz. The transfer function below shows the RF OUT of the PD v. the drive to the laser. I didn't divide out by the 1811 because its not on the EE bench.

4568

Tue Apr 26 01:20:02 2011

The performance plots for POX_11 in the wiki are horrendous and the schematic is missing.

I opened up the box and found all kinds of horrors. There were multiple tunable parts and a flurry of excess nonsense.

The top 2 worst offenders:

1) The main tunable inductor was busted. I removed it and found that the coil was open. Too much indelicate soldering in its vicinity had melted the wire. Someone had put extra inductors and capacitors around it to make it seem as if the PD was working fine, but the noise performance was off by a factor of ~100.

2) The MAX4107 had a 1.4k series resistor. This make the output go through a 1450/50 voltage division which is not nice for the SNR. I removed it.

I then struggled for awhile to get a sensible response. It turned out that the TEST IN input was not giving me a sensible TF. Jenne and I fired the Jenne laser at it and found that the 11 MHz main resonance is there. In the morning I'll finish this off and post more results. I think its going to end up being fine.

We are going to have to take a careful look at all the RFPDs if this one is any indication...

4567

Mon Apr 25 22:38:49 2011

prepration for DRMI : Y arm flashing

This week is going to be a recycled Michelson week.

As a preparation I did several things today :

1. Alignment of the Y arm

2. Alignment of PRM

3. Checking of all the pick-off ports

(Y arm alignment)

The idea to have the Y arm aligned is that : once we lock the Y arm we will be able to align the input PZTs using the Y arm as a reference.

I tried aligning the Y arm and successfully made the Y arm flashing with IR. I can see it flashing on ITMY camera but no flashing on ETMY camera.

(PRM alignment)

PRM has been intentionally misaligned for the single arm green locking test.

I just confirmed that we can bring PRM back to a good alignment. Now we can see the central part is flashing too.

(picked-off beams)

I went checking through all the picked off beams to see if they are available or not.

POX : lost

POY : fine

POP : very clipped

POSRM : fine

4566

Mon Apr 25 12:55:35 2011

Quote:

40m wiki seems to have been down for quite a while now but I can't see any info in the elog about it. Is there some ongoing problem?

There was an email from Dave Barker about this. They had to reorganize the DNS at LHO. The URL that should be used is: http://blue.ligo-wa.caltech.edu:8000/40m

Thanks Jamie, I've updated the links from the ATF wiki to reflect this.

4565

Mon Apr 25 12:55:19 2011

Quote:

40m wiki seems to have been down for quite a while now but I can't see any info in the elog about it. Is there some ongoing problem?

There was an email from Dave Barker about this. They had to reorganize the DNS at LHO. The URL that should be used is: http://blue.ligo-wa.caltech.edu:8000/40m

Nope. I know I had the right address, and it was down for me too all weekend. It's better now though. blue.ligo-wa.caltech.edu was up though.

4564

Mon Apr 25 11:58:37 2011

Quote:

40m wiki seems to have been down for quite a while now but I can't see any info in the elog about it. Is there some ongoing problem?

There was an email from Dave Barker about this. They had to reorganize the DNS at LHO. The URL that should be used is: http://blue.ligo-wa.caltech.edu:8000/40m

4563

Mon Apr 25 11:23:41 2011

40m wiki seems to have been down for quite a while now but I can't see any info in the elog about it. Is there some ongoing problem?

4562

Sun Apr 24 21:37:40 2011

review of triple resonant EOM : model looks fine

IOO

To design a new resonant EOM box I started reviewing the prototype that I've built.

As a part of reviewing I checked an important thing that I haven't carefully done so far :

I compared the measured input impedance with that of predicted from a circuit model. I found that they show a good agreement.

So I am now confident that we can predict / design a new circuit performance.

* * * (input impedance) * * *

Performance of a resonant circuit is close related to its input impedance and hence, in other words, determined by the input impedance.

Therefore an investigation of input impedance is a way to check the performance of a circuit. That's why I always use impedance for checking the circuit.

The plot below is a comparison of input impedance for the measured one and one predicted from a model. They show a good agreement.

(Note that the input impedance is supposed to have 50 Ohm peaks at 11, 29.5 and 55 MHz.)

* * * (circuit model) * * *

To make the things simpler I assume the following three conditions in my model:

1. inductor's loss is dominated by its DC resistance (DCR)

2. capacitor's loss is characterized only by Q-value

3. Transformer's loss is dominated by DCR and its leakage inductance

All the parameters are quoted from either datasheet or my measurement. The model I am using is depicted in the schematic below.

Basically the Q-vaules for the capacitors that I used are quite low. I think higher Q capacitors will improve the performance and bring them to more 50 Ohm.

4561

Fri Apr 22 12:07:38 2011

josephb, steve

Removed hanging D-sub to SCSI in 1X2

Problem:

Way back, Jay had D-sub to SCSI adapters made to adapt our existing Sander box AA filters to the new SCSI based IO chassis. However, these did not fit inside the box.

At the time, we simply left the cards outside hanging, which was a hack and needed to be replaced.

Solution:

Steve modified a black AA filter box so that it could fit the D-sub to SCSI adapter board on it, plus strain relief the SCSI cable, rather than let it hang. The back of the box was cut, and an extending piece of metal attached to the bottom of the box. The adapter board was screwed into the box, the SCSI plugged in, then the SCSI cable is clamped to the extending metal as well.

This modification will be propagated to the 3 remaining AA filter boards using the D-sub to SCSI adapter.

4560

Fri Apr 22 11:08:50 2011

demod board AS11 : amplitude imbalance

Amplitude imbalance between I and Q in a demod board, AS11, with the new 90 deg splitter was measured.

It shows roughly 10% amplitude imbalance when the LO power is in a range from 0 to 5 dBm. Not so bad.

With the handmade coil there used to be a huge imbalance (either I or Q goes to zero volt while the other keeps about 1 V rms) as the LO power decreases.

But with the new 90 deg splitter now there are no more such a huge imbalance.

The remaining 10 % imbalance possibly comes from the fact that we are using ERA-5 in each I and Q path. They may have such gain imbalance of 10%.

We should check the ERA-5 gains so that we can confidently say ERA-5 causes the amplitude imbalance.

Then our plan replacing the ERA-5s (see here) will sound more reasonable.

Quote from #4555

The new 90 deg splitter works better.

I will also measure amplitude unbalances between I and Q.

4559

Fri Apr 22 10:28:22 2011

You should be able to resolve the other harmonics by decreasing the IF BW or RBW on the analyzer. Even though
they're OK, its useful to have the final measurement of all of them in some kinds of physical units (like dBm, but
not dBm/Hz or dB or dBcubits).

4558

Fri Apr 22 09:25:43 2011

Suresh

RF Source: Temperature sensor relocated

RF Amp operating temperature

Earlier measurement reported by Alberto in LIGO-T10004-61-v1 based on the LM34 temperature sensor were lower than that shown by placing a calibrated thermocouple sensor directly on the heat sink by about 5deg C. The difference probably arose because the LM34 was located on a separate free-hanging copper sheet attached to the RF Amp by a single screw, resulting in a gradient across the copper strip. I tried to move the LM34 which was glued down, but broke the leads in the process. I then replaced it with another one mounted much closer to the heat sink and held it down with a copper-strip clamp. There is no glue involved and there is heatsink compound between the flat surface of the LM34 and the heatsink. Picture attached.

The picture also shows the new filters which have been put in place to reduce the harmonics. Note that the SBP-10.7 which was to go on the 11 MHz Demod output is located much farther upsteam due to space constraints.

4557

Fri Apr 22 09:05:53 2011

As seen in the previous measurement the first harmonic of both the 11 MHz and 55 MHz outputs are about 30dB
higher than desired.  In an attempt to attenuate these and higher harmonics I introduced SBP-10.7 filters into
the 11MHz outputs and SLP-50 filters into the 55 MHz outputs.
Then I measured the height of the harmonics again and found that they were suppressed as expected.  Now harmonic
at 22 MHz is 58dB lower than the 11 MHz fundamental.  And the 110 MHz is lower by 55 dB compared to the 55 MHz
fundamental.  None of the higher harmonics are seen => they are below 70dB

SLP-50 has an insertion loss(IL) of 4.65 dB and Return Loss(RL) of 3dB.  It would be better to use SBP-60
(IL=1.4 dB and RL=23dB)

The filter on the 11 MHz lines is okay. The SBP-10.7 has IL=0.6 dB and RL=23 dB.

4556

Fri Apr 22 02:10:53 2011

Restarted the elog with the script.

4555

Thu Apr 21 21:46:22 2011

demod board : new 90 deg splitter

A less LO power dependence on the relative phase was found. The new 90 deg splitter works better.

From -3 dBm to 10 dBm in LO power, the relative phase is within 90 +/- 5 deg.

As a comparison I plot the phase that I measured when the handmade coil had been there (green curve in the plot).

I will also measure amplitude unbalances between I and Q.

Quote from #4554

A 90 degree splitter, PSCQ-2-51W, has arrived today and I installed it on a demod board called AS11.

Results of the I-Q phase measurement with the new splitter will be reported soon.

4554

Thu Apr 21 21:24:41 2011

demod board : new 90 deg splitter

A new 90 degree splitter, PSCQ-2-51W, has arrived today and I installed it on a demod board called AS11.

Results of the I-Q phase measurement with the new splitter will be reported soon.

* Picture 1 = before removal of the handmade coil

* Picture 2 = after removal of the coil and the associated capacitors

* Picture 3 = after soldering PSCQ-2-51-W

Quote from #4358

First of all we will replace the home-made 90 degree splitter (see this entry) by a commercial splitter, PSCQ-2-51-W+ from Mini circuit. This is the step 1 basically.

4553

Thu Apr 21 15:20:46 2011

PEM

PSL enclosure work today

Quote:

The east side window guides will be replaced by one long U-channel. There will be drilling into 2x2 steel frame. It should be done by 2pm today

This should remove the jerking motion of windows hitting the individual guides.

The installation went smoothly. There will be no more banging the doors into guides on the east side.

Atm2 showing the west side as is today

Attachment 1: P1070558.JPG

Attachment 2: P1070560.JPG

4552

Thu Apr 21 15:03:29 2011

juction board finds home

The anti aliasing box was opened up at the back to accommodate the junction board and the SCSI cable towards the ADC. Aluminum plate was attached to the bottom to hold the strain relief clamp.

Three more hanging junction cards will be replaced in this manner.

Attachment 1: P1070570.JPG

Attachment 2: P1070568.JPG

4551

Thu Apr 21 14:39:43 2011

new strain relieved N connectors at AP

New right angle PVC, 2 x 2 x 1/4" installed at the AP table to strain relief the 1/4" spiral corrugated RF coaxes.

Attachment 1: P1070562.JPG

Attachment 2: P1070564.JPG

4550

Thu Apr 21 08:26:42 2011

PEM

PSL enclosure work today

The east side window guides will be replaced by one long U-channel. There will be drilling into 2x2 steel frame. It should be done by 2pm today

This should remove the jerking motion of windows hitting the individual guides.

4549

Wed Apr 20 23:20:49 2011

jamie

Summary

installation of CDS tools on pianosa

This is an overview of how I got (almost) all the CDS tools running on pianosa, the new Ubuntu 10.04 control room work station.

This is machine is experiment in minimizing the amount of custom configuration and source code compiling. I am attempting to install as many tools as possible from existing packages in

available packages

I was able to install a number of packages directly from the ubuntu archives, including fftw, grace, and ROOT:

apt-get install \
 libfftw3-dev \
 grace \
 root-system

LSCSOFT

I installed all needed LSCSOFT packages (framecpp, libframe, metaio) from the well-maintained UWM LSCSOFT repository.

$ cat /etc/apt/sources.list.d/lscsoft.list
deb http://www.lsc-group.phys.uwm.edu/daswg/download/software/debian/ squeeze
deb-src http://www.lsc-group.phys.uwm.edu/daswg/download/software/debian/ squeeze contrib

sudo apt-get install lscsoft-archive-keyring
sudo apt-get update
sudo apt-get install ldas-tools-framecpp-dev libframe-dev libmetaio-dev lscsoft-user-en

You then need to source /opt/lscsoft/lscsoft-user-env.sh to use these packages.

EPICS

There actually appear to be a couple of projects that are trying to provide debs of EPICS. I was able to actually get epics working from one of them, but it didn't include some of the other needed packages (such as MEDM and BURT) so I fell back to using Keith's pre-build binary tarball.

Prereqs:

apt-get install \
 libmotif-dev \
 libxt-dev \
 libxmu-dev \
 libxprintutil-dev \
 libxpm-dev \
 libz-dev \
 libxaw7-dev \
 libpng-dev \
 libgd2-xpm-dev \
 libbz2-dev \
 libssl-dev \
 liblapack-dev \
 gfortran

Pulled Keith's prebuild binary:

cd /ligo/apps
 wget https://llocds.ligo-la.caltech.edu/daq/software/binary/apps/ubuntu/epics-3.14.10-ubuntu.tar.gz
 tar zxf epics-3.14.10-ubuntu.tar.gz

GDS

I built GDS from svn, after I fixed some broken stuff [0]:

cd ~controls/src/gds
svn co https://redoubt.ligo-wa.caltech.edu/svn/gds/trunk
cd trunk
#fixed broken stuff [0]
source /opt/lscsoft/lscsoft-user-env.sh
./bootstrap
export GDSBUILD=online
export ROOTSYS=/usr
./configure --prefix=/ligo/apps/gds --enable-only-dtt --with-epics=/ligo/apps/epics-3.14.10
make
make install

dataviewer

I installed dataviewer from source:

cd ~controls/src/advLigoRTS
svn co https://redoubt.ligo-wa.caltech.edu/svn/advLigoRTS/trunk
cd trunk/src/dv
#fix stupid makefile /opt/rtapps --> /ligo/apps
make
make install

I found that the actual dataviewer wrapper script was also broken, so I made a new one:

$ cat /ligo/apps/dv/dataviewer
#!/bin/bash
export DVPATH=/ligo/apps/dv
ID=$$
DCDIR=/tmp/${ID}DC
mkdir $DCDIR
trap "rm -rf $DCDIR" EXIT
$DVPATH/dc3 -s ${NDSSERVER} -a $ID -b $DVPATH "$@"

environment

Finally, I made a environment definer file:

$ cat /ligo/apps/cds-user-env.sh
# source the lscsoft environment
. /opt/lscsoft/lscsoft-user-env.sh

# source the gds environment
. /ligo/apps/gds/etc/gds-user-env.sh

# special local epics setup
EPICS=/ligo/apps/epics
export LD_LIBRARY_PATH=${EPICS}/base/lib/linux-x86_64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=${EPICS}/extensions/lib/linux-x86_64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=${EPICS}/modules/seq/lib/linux-x86_64:$LD_LIBRARY_PATH
export PATH=${EPICS}/base/bin/linux-x86_64:$PATH
export PATH=${EPICS}/extensions/bin/linux-x86_64:$PATH
export PATH=${EPICS}/modules/seq/bin/linux-x86_64:$PATH

# dataviewer path
export PATH=/ligo/apps/dv:${PATH}

# specify the NDS server
export NDSSERVER=fb

[0] GDS was not compiling, because of what looked like bugs. I'm not sure why I'm the first person to catch these things. Stricter compiler?

To fix the following compile error:

TLGExport.cc:1337: error: ‘atoi’ was not declared in this scope

I made the following patch:

Index: /home/controls/src/gds/trunk/GUI/dttview/TLGExport.cc
===================================================================
--- /home/controls/src/gds/trunk/GUI/dttview/TLGExport.cc	(revision 6423)
+++ /home/controls/src/gds/trunk/GUI/dttview/TLGExport.cc	(working copy)
@@ -31,6 +31,7 @@
 #include <iomanip>
 #include <string.h>
 #include <strings.h>
+#include <stdlib.h>
 
 namespace ligogui {
    using namespace std;

To fix the following compile error:

TLGPrint.cc:264: error: call of overloaded ‘abs(Int_t&)’ is ambiguous

I made the following patch:

Index: /home/controls/src/gds/trunk/GUI/dttview/TLGPrint.cc
===================================================================
--- /home/controls/src/gds/trunk/GUI/dttview/TLGPrint.cc	(revision 6423)
+++ /home/controls/src/gds/trunk/GUI/dttview/TLGPrint.cc	(working copy)
@@ -22,6 +22,7 @@
 #include <fstream>
 #include <map>
 #include <cmath>
+#include <cstdlib>
 
 namespace ligogui {
    using namespace std;

4548

Wed Apr 20 22:29:07 2011

The suggested layout of the 1Y2 Rack is shown below.

To simplify the wiring, I have largely kept demod boards with the same same LO frequency close to each other.

The Heliax cables land on the top and bottom of the of subracks. These are currently flexible plastic sheets. Steve has agreed to replace them with something more rigid. It would be good to have eight N-type connectors on the top and eight at the bottom. As demod boards occur in sets of eight per subrack. So it would be convenient if the 11 and 55 Mhz Heliax cables land on the top and the rest at the bottom. In the layout I have shown the current situation.

The LO signals to the boards come from the RF Distribution box and this is kept in the middle so that cables to both the subracks can be kept short.

The outputs of the AA filter boards from both subracks have to be connected to the SCSI Interface board with a twisted pair ribbon cable.

4547

Wed Apr 20 21:53:01 2011

Suresh

RF system: Stray heliax cable

We found a stray unused heliax cable running from the LSC rack 1Y2 to a point between the cabinets 1X3 and 1X4. This cable will need to be redirected to the AS table in the new scheme. It is labled C1LSC-PD5 The current situation has been updated as seen in the layout below

Attachment 1: rogue_cable_1.png

4546

Wed Apr 20 20:42:55 2011

VIDEO

today's video session

[Steve / Suresh / Kiwamu]

90 % of unused video cables have been removed.

Still a couple of video cables are floating around the video MUX. They will be removed in the next week's session.

4545

Wed Apr 20 11:02:18 2011

MEDM screens and Front Ends updated to new Matrices

We simply didn't any matrices larger than 16x16. If we had, than that matrix would not have worked properly since the beginning.

Quote:

Just a curiosity:

I just wonder how you have distingushed the difference between _111 and _111.

They are equivalent alone themselves. Have you looked at the contexts of the lines?
Or you just did not have the larger matrix than 16x16, did you?

4544

Tue Apr 19 17:34:02 2011

Koji

MEDM screens and Front Ends updated to new Matrices

Just a curiosity:

I just wonder how you have distingushed the difference between _111 and _111.

They are equivalent alone themselves. Have you looked at the contexts of the lines?
Or you just did not have the larger matrix than 16x16, did you?

4543

Tue Apr 19 15:48:43 2011

MEDM screens and Front Ends updated to new Matrices

Problem:

The original matrix naming conventions for the front ends was broken. It used _11, _12,...,_1e, _1f, _110, _111 and so forth. The code was changes to use _1_1, _1_2,...,_1_16,_1_17, and so on.

In addition the matrix of filter banks was modified to use the same naming convetion (instead of starting at zero, it now start with one).

Work Done:

I rebuilt all the models, and restarted them all.

I wrote a simple script to modify the burt restore files to have the correct names for all the stored matrix values.

I also modified all the suspension screens, by modifying the default screens in /opt/rtcds/caltech/c1/medm/master/

The C1SUS, C1SCX, C1SPX, C1SCY, C1SPY, and C1MCS models had their foton filter files modified to put filters into the newly changed named filters

4542

Mon Apr 18 21:14:53 2011

Jamie

new control room machine: pianosa

Also, op440m's Sun monitor did not work well with pianosa, so I'm lending pianosa my HP monitor until we can get a suitable replacement.

4541

Mon Apr 18 21:09:45 2011

Jamie

new control room machine: pianosa

I've just installed the new control room machine: "pianosa". It is a replacement for the old sun machine "op440m" [0].

Hardware:

dual dual-core Intel Core i7-2600 CPU @ 3.40GH, hyperthreaded to provide 8 effective cores
16G memory (4x 4G dimms)
nVidia GF108 GeForce GT 430

It's now running Ubuntu 10.04 LTS 64bit. Unfortunately, the default 10.04 kernel is 2.6.32, which does not support pianosa's apparently very new network adapter, which is (from lspci):

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)

To get around this I temporarily added a PCI nic so that I could get on the network. I then added the Ubuntu kernel team PPA archive and installed linux-image-2.6.38-2, which is new enough to have the needed network driver, but not completely bleeding edge:

sudo add-apt-repository ppa:kernel-ppa/ppa
sudo apt-get update
sudo apt-get install linux-image-2.6.38-2-generic linux-headers-2.6.38-2-generic

Once the built in nic was working I removed the temporary one. Everything seems to be working fine now.

I have not yet done any configuration to integrate pianosa into the CDS network. I'll do that tomorrow.

[0] op44m has been moved into the control room rack next to linux1, in headless mode. If there is still a need to run scripts that only run on solaris, op440m can still be accessed via ssh as normal. Hopefully we can fully decommission this machine soon.

[1] https://launchpad.net/~kernel-ppa/+archive/ppa

4540

Mon Apr 18 17:47:41 2011