40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 7 of 339  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  825   Mon Aug 11 15:07:49 2008 josephbConfigurationComputersProcyon aka fb40m switched to new switch
I've connected Procyon to the Prosafe 24 port switch with a new, labeled Cat6 cable. Quick tests with dataviewer shows that its working.
  828   Tue Aug 12 12:21:13 2008 josephbConfigurationCamerasVariation in fit over 140 images for GC650 and GC750
Used matlab to calculate Gaussian fits on 145 GC650 images and 142 GC750 images. These were individual images (no averaging) looking at the PSL output from May 29th 2008. The GC650 and GC750 were looking at a split, but had different exposure values, slightly different distances to the nominal waist of the beam, and were not centered on the beam identically. Mostly this is a test of the fluctuations in the fit from image to image.

Note the mm refer to the size or position on the CCD or CMOS detector itself.
GC650

Mean
Amplitude  X center       Y center       X waist  Y waist  Background offset from zero
           position (mm)  position (mm)  (mm)     (mm)
0.3743     1.7378         2.6220         0.7901   0.8650  0.0047

Standard Deviation
Amplitude  X center       Y center       X waist  Y waist  Background offset from zero
           position (mm)  position (mm)  (mm)     (mm)
0.0024     0.0006         0.0005         0.0005   0.0003  0.00001

Std/Mean x100 (percent)
Amplitude  X center       Y center       X waist  Y waist  Background offset from zero
           position (mm)  position (mm)  (mm)     (mm)
0.6%       0.03%          0.02%          0.06%    0.04%    0.29%


GC750

Mean
Amplitude  X center       Y center       X waist  Y waist  Background offset from zero
           position (mm)  position (mm)  (mm)     (mm)
0.2024     2.5967         1.4458         0.8245   0.9194  0.0418

Standard Deviation
Amplitude  X center       Y center       X waist  Y waist  Background offset from zero
           position (mm)  position (mm)  (mm)     (mm)
0.0011     0.0005         0.0005         0.0003   0.0005  0.00003

Std/Mean x100 (percent)
Amplitude  X center       Y center       X waist  Y waist  Background offset from zero
           position (mm)  position (mm)  (mm)     (mm)
0.6%       0.02%          0.04%          0.04%    0.05%    0.07%
  831   Wed Aug 13 17:00:59 2008 steveConfigurationSUSBS sat amp removed
The PRM sat amp is broken. Ben is working on it.
The BS sat amp was removed from the BS sus and it is used with the PRM in
order to damp it for wire stand-off alignment.
  836   Thu Aug 14 19:08:14 2008 YoichiConfigurationSUSFree swing measurement going on
I started free swinging spectra measurement of all the suspensions now Aug 14 19:05 (PDT).
The watch dogs are all shutdown. Please do not turn them back on until tomorrow morning.
  839   Fri Aug 15 11:52:32 2008 josephbConfigurationCamerasMulti-computer display and recording of digital camera output
Through the magic of gstreamer, I've been able to live play on one machine, compress the image, send it to another machine via udp, and also display it there. The "tee" function also allows one to save at the same images at time as well.

The command line used on the "server", say Rosalba or Mafalda is:

CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 100 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! tee name=t1 t1. ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! ximagesink t1. ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host="131.215.113.103" port=5000

This both displays the image and sends it to the host 131.215.113.103 in this case.

I've written a primitive shell script that does most of this.

It requires at the minimum an IP address. You can also give it a number of images (the -m number) and also the exposure value (-E 20000).

Currently in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode/ there is a script called CameraServerScript.

Typing in "CameraServerScript 131.215.113.107" would send it to that IP address.

Typing in "CameraServerScript 131.215.113.107 500 40000" would run for 500 images at an exposure value of 40000.

To actually receive, you need gstreamer installed and run the following command:

gst-launch udpsrc port=5000 ! smokedec ! queue ! ffmpegcolorspace ! ximagesink sync=false

Make sure you have the right IP address to send to.

Still working on multicasting (basically a server is constantly sending out images, and the client subscribes to the multicast).
  843   Fri Aug 15 19:32:49 2008 steveConfigurationVACpumpdown complete
I have just reached vacuum normal. The maglev peaked at 49.8C body temp with aux fan on at 3.2 Torr
cc1 1e-4Torr

note: pumpdown was put on hold for Koji's goodby lunch
  844   Mon Aug 18 08:07:10 2008 YoichiConfigurationSUSSuspension free swinging
I've started a free swinging measurement of OSEM spectra now. Please leave the watchdogs untouched.
  847   Mon Aug 18 15:32:18 2008 josephbConfigurationCamerasHow to multicast with gstreamer and Gige Cameras
In order to get multicasting to work, one simply needs to understand the address scheme.

In general, the address range 224.0.0.0 - 239.255.255.255 are reserved for multicasting. Within in this address space, there are some base level operations in the 224.0.0.x range which shouldn't be interfered with.

For a single site, the address range between 239.252.0.0 and 239.255.255.255 is probably best.

Gstreamer and the current 40m network hubs are designed to handle this kind of communication already, so one merely needs to point them at the correct addresses.

While in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode type:

CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host=239.255.1.1 port=5000

This will multicast to the 239.255.1.1 address, using port 5000.

On the machine you wish to subscribe type:

gst-launch udpsrc multicast-group=239.255.1.1 port=5000 ! smokedec ! ffmpegcolorspace ! ximagesink sync=false
  852   Tue Aug 19 13:34:58 2008 josephbConfigurationComputersSwitched c1pem1, c0daqawg, c0daqctrl over to new switches
Moved the Ethernet connections for c1pem1, c0daqawg, and c0daqctrl over to the Netgear Prosafe switch in 1Y6, using new cat6 cables.
  857   Tue Aug 19 19:14:17 2008 YoichiConfigurationDAQFixed C1:IOO-MC_RFAMPDDC
Yoichi, Rob

C1:IOO-MC_RFAMPDDC, which is a PD at the transmission port of the MC, was not recording sensible values.
So I tracked down the problem starting from the centering of the beam on the PD.
The beam was hitting the PD properly. The DC output BNC on the PD provided +1.25V output when the light was
falling on the PD. The PD is fine.
The flat cable from the PD runs to the IOO rack and fed into the LSC PD interface card.
The output from the interface card is connected to a VMIC3113A DAQ card, through cross connects.
The voltages on the cross connects were ok.
The VMIC3113A was controlled by an EPICS machine (c1iool0). So it provides only a slow channel.
By looking at C1IOOF.ini and tpchn_C1.par, I figured that C1:IOO-MC_RFAMPDDC is using chnnum=13639 in the RFM
network and it is named C1:IOO-ICS_CHAN_15 in the .par file. So it is reading values from the ICS DAQ board.
Actually nothing was connected to the channel 15 of the ICS board and that was why C1:IOO-MC_RFAMPDDC was reading
nothing. So I took the PD signal from the cross connect and hooked it up to the Ch15 of the ICS DAQ through
the large black break out box with 4-pin LEMOs. Now C1:IOO-MC_RFAMPDDC reads the DC output of the PD.
I also put an ND filter in front of the RFAMPD to avoid the saturation of the ADC. The attenuation should have been done
electronically, but I was too lazy. Since the ND filter changes the Stochmon values, someone should remove it and reduce the
gain of the LSC PD interface accordingly.
  865   Thu Aug 21 10:24:20 2008 steveConfigurationSAFETYlaser safe mode condition
The MOPA and PSL shutters are closed.
Manual beam blocks are in place.
Enclosure interlock is enabled.
No other high power laser is in operation.

We are in laser safe of operation for visiting students from Japan

NO safety glasses required
  866   Thu Aug 21 16:28:59 2008 steveConfigurationSAFETYsafety glasses required
I just opened the MOPA shutter so PA is warming up.

High power beam path is cleared and laser safety glasses required.
  880   Mon Aug 25 14:42:09 2008 EricConfigurationCamerasETMX Digital Camera
I changed the lens on the camera looking at the ETMX to a 16mm, 1:1.4 zoom lens. This is in preparation to measure a couple parameters that depend on the camera's position and angle, so please avoid repositioning it for a couple of days.
  883   Mon Aug 25 21:15:23 2008 ranaConfigurationLSCaux NPRO off
Looks like no one has used the Lightwave NPRO on the AS table after Koji left, so I turned it off so that it can rest until Alberto does the X-arm measurements.
  884   Tue Aug 26 09:04:59 2008 ranaConfigurationPSLPMC Servo Board: Out for Repairs
I've started modifying our PMC board to bring it up to the 21st century - leave the screen alone or else you might zap something.
  887   Tue Aug 26 15:06:16 2008 steveConfigurationVACrga scan
Pumpdown 66 PRM-maglev vac normal -day 11
short form: pd66PRM-m-d11
  893   Thu Aug 28 18:56:14 2008 ranaConfigurationPSLbeam block distorted
There was a beam block after the Mach Zender. Who or what put this there?

The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??

Use the ELOG people...its good for you.
  896   Fri Aug 29 10:20:32 2008 YoichiConfigurationPSLbeam block distorted

Quote:
There was a beam block after the Mach Zender. Who or what put this there?

The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??

Use the ELOG people...its good for you.


I put the block. I was frequently reaching to the FSS box to change the test point probes. I put the block to protect my hands/clothes from being burnt accidentally.
  897   Fri Aug 29 11:01:49 2008 josephbConfigurationComputersAttempt to change a channel gain in ICS-110B
As noted earlier by Rana, I was playing around with the /cvs/cds/caltech/chans/daq/C1IOOF.ini file with help from Rob. I had made a backup before hand and saved it as C1IOOF.ini.Aug-28-2008. (I have since been informed that C1IOOF.ini.082808 would have been prefered as a name).

We had been trying to up the gain in the C1: PSL-ISS_INMONPD_F in order to do a very low power PMC sweep, in an attempt to get clean modes for fitting. Initially we pressed the reconfig button on the C0DAQ_DETAIL screen, but all that seemed to do was change the Config File CRC. We proceeded to reboot fb40m remotely. However, any change to the ini file (even an extra space at the end of the file) caused a 0x2000 status for C1IOVME16k on the C0DAQ_DETAIL screen. At the time I presumed it was comparing the CRC of the ini-file to something else.

Digging around on in Alex's webspace at http://www.ligo.caltech.edu/~aivanov/ , I found the NDS Access page, which indicated that 0x2000 was a conflict between the front-end and frame builder .ini files.

"There is also status bit 0x2000 which gets added when the DCU configuration is different in front-end and frame builder. That is you can change and .ini file an then reload DAQ configuration with Epics button, which reconfigures the front-end, but leaves frame builders with invalid old configuration. They will detect this change and set the status to 0x2000 to indicate this condition. You will have to restart frame builders to pick up new .ini file and set status back to zero for the affected DCU."

It was when I was going to try reseting the c1iovme via the C0DAQ_RFMNETOWRK medm screen that we realized the EPICS controls were not responding properly. The .ini file was returned to its original form, and mass reboots commenced.
  899   Fri Aug 29 12:41:26 2008 josephb, EricConfigurationComputersMore front ends moved to new network
Used Cat6 cables to finish moving all the front ends in 1Y4 and 1Y5 over to the new GigE network switches, specifically to the switch in 1Y6. This included the ones labeled c1susvme2, c1sosvme, and c1dscl1epics0.
  902   Fri Aug 29 16:35:18 2008 YoichiConfigurationPSLbeam block distorted

Quote:
There was a beam block after the Mach Zender. Who or what put this there?

The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??

Use the ELOG people...its good for you.


The apparent distortion of the MC refl. was caused by mis-alignment of the MC mirrors.
Because the MC1 was mis-aligned, the reflected light was clipped by a steering mirror.
I restored the MC angle bias values from the conlog history and now the MC locks.
According to conlog, the MC alignment was changed at around 18:30 on Thursday PDT.
It could have been caused by the computer reboots.
  903   Fri Aug 29 17:39:25 2008 ranaConfigurationPSLPMC: ADC Channels
The attached PNG shows the PMC error and controls signals with no calibration.

There are 3 states:

DARK - RF input disabled & output blanked. This should be a measure of the ADC noise

(-10 dB) - This is with the gain slider down at 5 dB instead of the nominal 15 dB.

Looks like the Generic DAQ board whitening is good enough for these signal levels above ~1 Hz.

From the low and high gain spectra it also looks like the UGF is ~500 Hz with the gain at 15 dB.
  906   Sat Aug 30 13:28:01 2008 ranaConfigurationPSLPMC: List of changes
This is a list of changes made to the PMC board while we had it out for modifying the notch:

  • LC-LC 4th order low pass filter
  • Replace the AD797 (U2) with an OP27. AD797's are bad - do not use them anywhere for any reason. The OP27 is slower and has a 3x worse input noise but doesn't compromise the bandwidth or noise performance of the PMC by any significant amount. The rule is: use OP27 everywhere unless you have a very good reason why not.
  • There is no 'H1' jumper on board. R9 is 90.9 Ohms and R2=900 Ohms so that the U2 stage has a gain of 10.
  • Cut a trace and inserted a 500 Ohm resistor between U2-pin6 and U5A-pin2 (the AD602). The AD602 has a 100 Ohm input impedance which cannot be driven without limiting by the AD797 or the OP27. The 500 Ohm resistor makes it a driveable load for low level signals which is all that should be there since its the error point of the servo. it also becomes a 6:1 voltage divider. Since the AD602 has a fixed output voltage noise of 100 nV/rHz, this will limit the noise performance if the VGA gain is less than 20 dB, but whatever.
  • R11 7.87k -> 1.74k, R12 = 78.7k -> 700k. This increases the high frequency gain of that stage by 7.87/1.74 = 4.5 and lowers the low frequency pole from 2 to 0.2 Hz to give the PMC some more staying power at DC. The loop shape is now 1/f^2 in the 9-480 Hz band and so the phase dips enough to make it almost conditionally stable, but not quite.
  • C26 changed from ??? + a 30 pF trim cap into a fixed NNN pF cap to set the notch frequency for the 14.5 kHz body mode that we measured. Once our brick configuration is more settled we can increase the Q of this notch from small to big.
  • Grounded pin 5 of U14 & U15 (AD620). These have sometimes been used as "differential" drivers in LIGO by connecting this reference voltage pin to the remote ground of the next board. This has always lead to insidious oscillation and noise. This beauty also has an output noise of 100 nV/rHz. Just never use this chip if you can help it; we can make true differential drivers - we have the technology.

Of course, we didn't have a current version of a schematic sitting around so I printed out a Rev E schematic and marked it up with red pen. I'll post pictures later and put the schematic into the PSL schematics notebook. Would be useful to take the old schematic and update it in Acrobat so that we have something electronic.
  908   Mon Sep 1 19:23:17 2008 YoichiConfigurationPSLFSS on an auxiliary loop
Summary: The FSS is now temporarily disabled. Naturally, the MC won't lock. I will fix it tomorrow morning.

Today, I did the 4th item of my TO DO list.
Using a mini-circuit mixer and two SR560s, I constructed an auxiliary servo loop for the reference cavity.
With this loop, I was able to lock the reference cavity without using the FSS box.
By locking the reference cavity with this auxiliary servo, I was able to measure the PC path transfer function.
I will post the analyzed results later.

I borrowed the PD RF and the LO signals from the main FSS loop by power splitters. Therefore, the gain of the main FSS loop
is now about 3dB low. I tried to compensate it by increasing the EOM modulation depth, but the PC path is still a bit noisy.
Probably the already too low LO power is now seriously low (the LO power cannot be changed from EPICS).
Because I did not want to leave the PC path with large output overnight (it will heat up the PA85, and might cause damage, though unlikely),
I disabled the FSS for now.
  910   Tue Sep 2 09:58:42 2008 YoichiConfigurationPSLFSS on an auxiliary loop

Quote:
Summary: The FSS is now temporarily disabled. Naturally, the MC won't lock. I will fix it tomorrow morning.


Now I removed the power splitters for the aux. reference cavity servo. The FSS is back and the MC locks.
I'm now returning one of the active high-impedance probes to the Wilson house. They need it today.
We are left with only one active probe. If anyone finds another active probe in the 40m lab.,
please let me know (according to Rana we should have one more).
  913   Tue Sep 2 22:43:16 2008 YoichiConfigurationPSLUpdated FSS open loop TF
Since the LO level of the FSS servo was too low, I replaced the RF oscillator board with a combination of
a Stanford signal generator and an RF amplifier.
Right now, the POY RF amplifier is used for this purpose temporarily.
Now the LO level is about 16dBm. The RF power going into the EOM is attenuated by 20dB from the LO level.
I played with the cable length to get the phase right.
Then I was able to lock the FSS with the new RF signal source.

Attached is the open loop transfer function of the current FSS. Now the UGF is a bit above 200kHz, a factor of 2 improvement.
This gain was achieved with the common gain slider at 13.5dB and the fast gain = 30dB.
With the old RF oscillator board, UGF=100kHz was achieved with the common gain =30dB. Therefore, the increase of the LO gave
us a large signal gain.

Increasing the gain further, again ,makes the PC path crazy.
Rich suggested that this craziness was caused either by the slew rate limit of the PA85 or the output voltage limit of the bypass Op-amp(A829)
is hit.

TO DO:
* Look at the error signal spectrum to see if there is any signal causing the slew rate saturation at high frequencies.
* Find out what the RF signal level for the EOM should be. 20dB attenuation is an arbitrary choice.
* Find out the cross over frequency. Determine where the fast gain slider should be.
etc ...
  915   Wed Sep 3 18:43:19 2008 YoichiConfigurationElectronicsTwo more active probes
I found two active probes, an HP41800A and a Tektronix P6201.
Thanks John for telling me you saw them before.
Now we have three active probes, wow !
We have to find or make a power supply for P6201.
The manual of the probe is attached.
  916   Wed Sep 3 18:45:01 2008 AlbertoConfiguration PD3 gain
Alberto, Yoichi,

We found that the PD3 servo was unstable with a gain of 1, so we switched it to 0.5
  922   Thu Sep 4 11:33:25 2008 josephb, Eric, JenneConfigurationComputersAttempt to increase gain for C1:PSL-ISS_INMONPD_F via 110B
We were attempting to increase the gain on the channel C1:PSL-ISS_INMONPD_F in preparation to do a scan of the PMC at very low input power.

We started by adding a line to the C1:IOOF.ini file in /cvs/cds/caltech/chans/daq/ under that channel that said "gain=10.0". Before touching anything, the channel was outputting around 4000 counts.

We hit the reconfig button for c1iovme16k, then rebooted c1iovme (which turned out to do nothing) and then the framebuilder, in a method consistent with the wiki. This turned out to put the channel in an odd state, where it was showing very rapid, random spikes, virtually but still around 4000ish counts. We returned the file back to its original format, hit reconfig, and then rebooted the framebuilder. The channel however, was still behaving in the same broken way.

After poking around the PSL table, looking at some direct outputs, we came back and rebooted c1iovme and the framebuilder again, which fixed the channel, such that it was reading out correctly. Taking this as a sign that maybe we should reboot the framebuilder, then c1iovme to get the channel to load changes, we changed the file again to have "gain=10.0". Upon reboot of the framebuilder, the channel was still reading out fine, but at the same level. So we continued with the reboot of c1iovme. This still had no effect on the channel output.

The ini file has been set back at this point, however since Yoichi is working, I'm holding off doing a reconfig and reboot on the framebuilder until later.
  925   Thu Sep 4 16:24:56 2008 ranaConfigurationComputersAttempt to increase gain for C1:PSL-ISS_INMONPD_F via 110B

Quote:
We were attempting to increase the gain on the channel C1:PSL-ISS_INMONPD_F in preparation to do a scan of the PMC at very low input power.

According to the Wikipedia, certain esoteric mathematical
operations lead to the result that 4000 x 10 > 32768.
  930   Thu Sep 4 18:02:34 2008 rana, josephbConfigurationPEMAccelerometer gains increased by 10
We increased the Accelerometer gains by 10 by modifying the C1ADCU_PEM.ini file.
[C1:PEM-ACC_MC1_X]
chnnum=15014
gain = 10

etc.
The plot shows the before and after for one channel. The ADC noise floor is ~10^-2 counts/rHz in this plot so now
we can do much better noise subtraction.
  932   Fri Sep 5 09:56:14 2008 josephb, EricConfigurationComputersFunny channels, reboots, and ethernet connections
1) Apparently the I00-ICS type channels had gotten into a funny state last night, where they were showing just noise, exactly when Rana changed the accelerometer gains and did major reboots. A power cycle of the c1ioo crate and appropriate restarts fixed this.

2) c1asc looks like it was down all night. When I walked out to look at the terminal, it claimed to be unable to read the input file from the command line I had entered the previous night ( < /cvs/cds/caltech/target/c1asc/startup.cmd). In addition we were unable to telnet in, suggesting an ethernet breakdown and inability to mount the appropriate files. So we have temporarily run a new cat6 cable from the c1asc board to the ITMX prosafe switch (since there's a nice knee high cable tray right there). One last power cycle and we were able to telnet in and get it running.
  937   Mon Sep 8 15:38:57 2008 YoichiConfigurationPSLPOY RF amp is back to its original task
I temporarily fixed the busted ZHL-32A RF amplifier's power connector by simply soldering a cable to the internal circuit and pulling the cable out of the box through a hole for the power connector.
So I released the POY RF amplifier from the temporary duty of serving the FSS RF distribution and put it back to the original task,
so that Rob can finally re-start working on the lock acquisition.
Now the temporarily fixed ZHL-32A is sitting next to the IOO rack along with the power supply and a Stanford signal generator.
Please be careful not to topple over the setup when you work around there. They will be there until Peter's Wentzel RF box arrives.
  941   Thu Sep 11 11:29:14 2008 josephbConfigurationComputersFinal netgear switch in place in 1Y2
I've placed the final (of 4) Netgear prosafe 24 port switch at the very top of 1Y2. At that location, there are no holes left to screw into, so it has 4 rubber feet and is sitting on the top most signal generator. It has been plugged in and connected to the control room hub with a labeled cat6 ethernet cable.

Its IP address has been set to 131.215.113.253, and has the usual controls password if using the "Smart Wizard Discovery Tool" which comes on the Netgear CD. The CD can be found in the Equipment manuals filing cabinet under Netgear. This program unfortunately only runs on a window PC.

To Do: Fix the C1:ASC ethernet connection which is currently coming straight out the front door and connected to the 1X4 switch (again through the front door).
  948   Mon Sep 15 14:00:52 2008 josephbConfigurationComputers1Y9 Hub and C1asc
The 1Y9 switch is now using a labeled Cat6 cable in cable trays to connect to the main switch in the offices. In addition, the c1asc cable which had been coming out the door was fixed last Friday, and is now labeled, going out the top and connects to the hub in 1Y2.

Note: Do not connect new ethernet cable from switch to switch without disconnecting the old cable to the rest of the network - this tends to make the Ethernet network unhappy with white flashing alarms.
  949   Tue Sep 16 10:57:45 2008 YoichiConfigurationPEMParticle counter gain
Summary:
Since we reduced the integration time of the particle counter by a factor of 10, we had to add a gain of 10
to the EPICS channels C1:PEM-count_full and C1:PEM-count_half.
I asked Alex to change it and he did it. I forgot to ask him to change the gain of C1:PEM-count_half. So now only
C1:PEM-count_full has x10 gain.

Detail:
C1:PEM-count_full and C1:PEM-count_half are 'Soft Channel' records in the database (Pcount.db). The values are actually
written into the VAL fields directly by an SNL code Particle.o.
Particle.o reads data from the RS-232C port, to which the particle counter is connected. Then it parses the data and put values
into relevant EPICS channels using channel access. This means we cannot change the gain of the channels by modifying the
database file. For example, ASLO field does not have any effect when the value is directly written into the VAL field.
We had to modify the SNL code. Alex modified Particle.st and the new SNL object file is Particle_x10.o sitting in 
/cvs/cds/caltech/target/c1psl/. I modified seq.load so that c1psl loads Particle_x10.o when rebooted.
The source code for the old Particle.st can be found on lesath.ligo.caltech.edu in
/export/CDS/d/epics/apple/Caltech/40mVac/40mVacScipe/dev/src
I asked Alex to disclose the location of the source of the new code.
In order to compile the SNL code into an object file for Motorola CPU by ourselves, we have to call Dave Barker at LHO.
  950   Tue Sep 16 13:04:22 2008 YoichiConfigurationPEMC1:PSL-FSS_RMTEMP alarm level changed
At the request of Steve, I modified the HIGH value of C1:PSL-FSS_RMTEMP from 21.27 to 23.0.
The HIHI is set to 23.50.
  951   Tue Sep 16 16:47:01 2008 peteConfigurationPSLPrototype FSS reference installed
After verifying output, I installed the new prototype 21.5 MHz FSS reference (Wenzel crystal oscillator and ZHL-2 amp). Yoichi and I successfully locked the MC, and have left the new reference in place. It's temporarily sitting on the corner of the big black optics table (AP table?).
  952   Wed Sep 17 12:55:28 2008 robConfigurationIOOMC length
I measured the mode cleaner length last night:

SR620                Marconi
                     199178070
165981524            165981725
                     132785380
                      33196345


I did the division in Marconi-land, rather than SR620-land.
If someone wants to do this in SR620-land, feel free to do it and post the numbers.
  954   Wed Sep 17 13:43:54 2008 YoichiConfigurationPSLRC sweep going on
I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over.
  957   Wed Sep 17 15:22:31 2008 YoichiConfigurationPSLRC sweep going on

Quote:
I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over.


The measurement is still going on.
I will post an entry when it is done.
Thank you for the patience.
  959   Wed Sep 17 17:58:35 2008 YoichiConfigurationPSLRC sweep going on
The cavity sweep is done. The IFO is free now.
  965   Thu Sep 18 14:36:54 2008 josephbConfigurationComputersName server and Epics
The problems Rob was experiencing last night was due to part of the setup (or rather testing of the setup) of the new nameserver running on linux1.

The name server was setup on linux1 by doing the following:

1) Installed xorg-x11-xauth via yum which was necessary to get remote x windows to work in linux1

2) Installed xorg-x11-fonts-Type1 in order to get the gui system-config-* programs to work

3) Ran system-config-bind, which created a default set of nameserver files. I unfortunately didn't understand the gui all that well, so I manually edited and added files to these base ones. The base files were generated in /var/named/chroot/etc/ and /var/named/chroot/var/named.

4) I added martian.zone and 113.215.131.in-addr.arpa.zone, named.conf.local, and edited named.conf so it loaded named.conf.local. The martian.zone file acts a forward look up (i.e. give it a name and it returns an IP number like 131.215.113.20). The 113.215.131.in-addr.arpa.zone acts as a reverse look up (i.e. give it an IP number like 131.215.113.20 and it tells you the name). The file named.conf.local merely points to these two files.

Note: One can add or change IP lookup by simply updating these two files. The format should be obvious from the files.

5) I specifically ssh'd in as root to linux1 (using su wasn't sufficient) and then typed "service named start" (without quotes). You can also use "restart" or "stop" instead of "start". This started the name server, giving an [Ok] message.

6) I edited the /etc/resolve.conf file on linux1 so that it pointed to itself first ("nameserver 127.0.0.1" at the top of the file). I also added the line "search martian", which allows one to simply use linux1 as opposed to linux1.martian.

I also edited the /etc/resolve/conf file on linux2, and it seems to resolve names fine.

7) And here is where I broke things. As a test, I moved /etc/hosts to /etc/hosts.bak, and then tested to see if names were being resolved correctly. By using the command host, I determined they were in fact working. I also tested with ssh.

However, something basic didn't like me moving the hosts file. Apparently when a front-end machine needed to reboot, it wouldn't come back up, without any ability to SSH or telnet into them.

With Yoichi and I did quite a bit of debugging this morning and determined the nameserver itself isn't conflicting, merely the lack of the host file was the source of the problem. One theory is that services don't know to go to DNS to resolve host names. I think by modifying the /etc/nsswitch.conf file to include dns as an option for services and other programs, it might work without the host file, however, I'm going to leave that to tomorrow morning which is less likely to interfere with current operations.

As it stands, things are working with the nameserver running and the host file in place.
  973   Fri Sep 19 11:21:45 2008 josephbConfigurationComputersNameserver and Rosalba
I tried modifying the nsswitch.conf file to include going to dns in addition to local files for everything (services, network, etc) and then moving the /etc/hosts file to /etc/hosts.bak. Unfortunately, this still didn't allow front-ends to reboot properly. So I'm not sure what is using the hosts file, but whatever it is, is apparently important. After the test I placed the hosts file back and reverted the nsswitch.conf file.

I also noticed that Rosalba was having problems connecting to the network. This apparently was because I had shut down the dhcp server on the NAT router, as had been discussed at the meeting on Wednesday.

To fix this, I modified the /etc/sysconfig/network-scripts/ifcfg-eth1 file to fix rosalba's ip as 131.215.113.24 (which doesn't seem to be in use). I also updated rosalba's /etc/resolv.conf file to point at linux1's name server, and two additional name servers as well, and added the "search martian" line. I modified the /etc/sysconfig/network-scripts/ifcfg-eth0 file so the built in network card doesn't come up automatically, since its currently not plugged into anything. Lastly, I added rosalba and its IP to linux1's name server files.
  980   Mon Sep 22 21:30:06 2008 ranaConfigurationPSLbad FSS
The MC refl power was going up and the FSS PC drive was so large that I had to turn up the FSS
common gain from 1.5 dB to 10.5 dB to get it to be better. Attached are the before (REF) and
after plots of frequency noise. Is the FSS gain really supposed to be 1.5 dB?? How did we gain
so many dB's of optical gain? Is there a loop measurement from after Peter's oscillator change?
  982   Mon Sep 22 22:24:19 2008 ranaConfigurationPSLbad FSS

Quote:
The MC refl power was going up and the FSS PC drive was so large that I had to turn up the FSS...


Looks like I bumped the PS for the 21.5 MHz test setup and changed the supply voltage of the amplifier
from +24 to +38 V. This made the amplifier go hot after a few hours and the output eventually dropped.

Yoichi and I walked out there now and it was too hot to touch. We turned it off and put it on a heat
sink to make it chill out and it came back after a few minutes. We have set the input to the amp to
be -7 dBm instead of -8 dBm after deciding that we should take into account the 1 dB loss in the cable
run and deliver a real +17 dBm to the mixer.

The right way is to calibrated the LO mon of the FSS.
  986   Tue Sep 23 15:28:06 2008 peteConfigurationPSLnew 21.5 MHz FSS reference installed
The new 21.5 MHz FSS reference is now installed in the rack with the 7 Sorensen PS. Both outputs give 18.7 dBm. The MC seems happy.

Bob did the +24 V and +15 V hookups for the amp and the Wenzel oscillator respectively, off of the din strips on the right of the rack.

I have attached two photographs. One shows the front of the box as mounted in the rack, and the other shows the inside of the box. From the second photo the circuit is apparent. Black wire coming in has ground, green has +15, and white has +24. After the switches, ground and +15 go to the Wenzel crystal oscillator, and ground and +24 go to the mini-circuits amp. There is 5 dB attenuation between the Wenzel 21.5 MHz output and the amp input. There is 3 dB attenuation between the amp output and the splitter.

The Wenzel crystal oscillator is their "streamline" model, and puts out 13.2 dBm. The amp is mini-circuits ZHL-2.
  988   Wed Sep 24 19:13:06 2008 ranaConfigurationComputer Scripts / Programsupdatedb & locate: megatron & rosalba
I ran updatedb as root today on megatron and rosalba just before the meeting.
It finished at ~14:10 on both machines so that's ~20 minutes total.

The default updatedb.conf for these guys also seems to be set up right so that
it is indexing the NFS mount (/cvs/cds/) so that's good. Next, someone needs to
add the updatedb command to the daily cron for each of these guys (5 AM) and
add this to the wiki page on how we set up new computers.

I also found that the root passwd on Megatron was different from all of the other
machines, indicating that perhaps megatron was trying to free himself. I have put
down that rebellion viciously
:D and he's now toeing the line.
  992   Thu Sep 25 14:03:08 2008 josephbConfigurationComputers 

Quote:

We (Joe) need to buy a GigE card for linux1 and to also set up conlog and conlogger to run on Nodus.


A spare Intel Pro 1000/GT desktop adapter (gigabit ethernet card) has been added to Linux1 and is now using that card to connect to the network.

This was after a slight scare when I somehow reset the bios on Linux1 during the first reboot after adding the card.
After some debugging and discussion with Yoichi, the bios was fixed and the computer works again, with its new faster network connection.

Although we both noted that Linux1 is a rather old machine, with only half a gig of Ram and reaching about 80% capacity on its 58 gigabyte hard drive (raid). Might be worth upgrading in general.

Need to figure out how to install conlog/conlogger programs next...
  994   Thu Sep 25 17:14:31 2008 ranaConfigurationGeneralnew sitemap
ELOG V3.1.3-