40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 295 of 341  Not logged in ELOG logo
ID Date Author Type Category Subject
  2321   Tue Nov 24 14:33:22 2009 AlbertoUpdateABSLworking on the AP table

I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.

  2320   Tue Nov 24 10:36:21 2009 KojiUpdateLSCMeasured MC length

What I meant was the VCO driver, not the FSS box.

As for the frequency, all written numbers were the Marconi displays.
The number on the frequency counter was also recorded, and so will be added to the previous entry shortly... 

Quote:

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

 

  2319   Tue Nov 24 08:00:16 2009 ranaUpdateLSCMeasured MC length

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

 

  2318   Mon Nov 23 21:36:38 2009 KojiUpdateIOOAligned PMC/RC

I aligned the beam goes to PMC. It increased the MC Trans from 8.25 to 8.30.

I also aligned the beam goes to RC.
When I touched the FSS box (wrong: this was the VCO driver) that was close to one of the steering mirror, suddenly the RC trans increased.
It is now 9.8. I am afraid that it gets saturated. I could not reproduce the phenomenon. This could be caused by a bad contact?
Note that I didn't see there is any loose optic.

Attachment 1: 091123_PSL.png
091123_PSL.png
  2317   Mon Nov 23 21:30:29 2009 JenneUpdateLSCMeasured MC length

With Koji's help, I measured the length of the Mode Cleaner.

The new modulation frequencies (as quoted on the Marconi front panels) are: 

165.980580 MHz

 33.196116 MHz

132.784464 MHz

199.176696 MHz

The Frequency Counter readback is 165980584.101 Hz (a 4Hz difference).  All of the Marconi's front-panel frequencies read ###.##### MHz Ext, and the Frequency standard has it's "locked" light illuminated, and the 1pps input light blinking, so I think everything is still nicely locked to the frequency standard, and the frequency standard is locked to the GPS.

While changing the marconi's, I accidentally touched the MC's 29.5 MHz marconi.  It is set back to the nominal value (according to Kiwamu's rack photos) of 29.485MHz.  But the phase might be sketchy, although hopefully this doesn't matter since we don't do a double demodulation with it.

I also ran the scripts in the wiki page: How To/Diagonalize DRMI Length Control to set the DD Phases.

 

 

  2316   Mon Nov 23 19:36:28 2009 JenneUpdateAdaptive FilteringHow to add ASS channels, so that they're saved to frames

[Jenne, Sanjit]

We would like several channels from the OAF/ASS screen to be saved to frames, so that we can use the channels for our OAF model.  In theory, this should involve uncommenting the desired channels in the .ini file (.../caltech/chans/daq/C1ASS.ini), and restart the frame builder.  Since this .ini file was generated a long time ago, and things have been changed since then, the chnnums in the .ini file and the corresponding .par file don't match up.  We need to go through the .par file (/cvs/cds/gds/param/tpchn_c3.par), and look up the chnnums for our channels, and copy those numbers into the .ini file.  Figuring out what was going on involved many fb40m restarts, but on the last one of the night, I restarted the backup script, so it should (hopefully) run tonight, and get all of the frames that we've been missing.

Notes to self: 

*  When adding channels to other front ends, the end of the process is to click the blue button on the C0DAQ_DETAIL screen next to your computer.  C1ASS isn't on that screen.  Instead, in the C1ASS_GDS screen, click DAQ Reload.

*  The channel names for the Test Points and the .ini files must be different.  That's why there's a '_2048' suffix at the end of every channel in our .ini file.

*  tpchn_C1 is all of the old-style system test points.  tpchn_C2 is the C1OMC, and tpchn_C3 is for the C1ASS testpoints.

*  When uncommenting channels in the C1ASS.ini file, make sure acquire is set to 1 for every channel we want saved.  The default in this .ini file is set to acquire = 0.

  2315   Mon Nov 23 17:53:08 2009 JenneUpdateComputers40m frame builder backup acting funny

As part of the fb40m restart procedure (Sanjit and I were restarting it to add some new channels so they can be read by the OAF model), I checked up on how the backup has been going.  Unfortunately the answer is: not well.

Alan imparted to me all the wisdom of frame builder backups on September 28th of this year.  Except for the first 2 days of something having gone wrong (which was fixed at that time), the backup script hasn't thrown any errors, and thus hasn't sent any whiny emails to me.  This is seen by opening up /caltech/scripts/backup/rsync.backup.cumlog , and noticing that  after October 1, 2009, all of the 'errorcodes' have been zero, i.e. no error (as opposed to 'errorcode 2' when the backup fails).  

However, when you ssh to the backup server to see what .gwf files exist, the last one is at gps time 941803200, which is Nov 9 2009, 11:59:45 UTC.  So, I'm not sure why no errors have been thrown, but also no backups have happened. Looking at the rsync.backup.log file, it says 'Host Key Verification Failed'.  This seems like something which isn't changing the errcode, but should be, so that it can send me an email when things aren't up to snuff.  On Nov 10th (the first day the backup didn't do any backing-up), there was a lot of Megatron action, and some adding of StochMon channels.  If the fb was restarted for either of these things, and the backup script wasn't started, then it should have had an error, and sent me an email.  Since any time the frame builder's backup script hasn't been started properly it should send an email, I'm going to go ahead and blame whoever wrote the scripts, rather than the Joe/Pete/Alberto team.

Since our new raid disk is ~28 days of local storage, we won't have lost anything on the backup server as long as the backup works tonight (or sometime in the next few days), because the backup is an rsync, so it copies anything which it hasn't already copied.  Since the fb got restarted just now, hopefully whatever funny business (maybe with the .agent files???) will be gone, and the backup will work properly. 

I'll check in with the frame builder again tomorrow, to make sure that it's all good.

  2314   Mon Nov 23 16:28:12 2009 steveSummaryCamerasVideo swicher options

Quote:

Steve is summarizing the Video Matrix choices into this Wiki page:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/VideoMUX

Requirements:

Price: < 5k$

Control: RS-232 and Ethernet

Interface: BNC (Composite Video)

Please check into the page on Monday for a final list of choices and add comments to the wiki page.

 Composite video matrix switchers with 32 BNC in and 32 BNC channels out are listed.

  2313   Mon Nov 23 11:03:00 2009 steveUpdateSUSjackhammer special well under control

Quote:

I've changed the watchdog rampdown script so it brings the SUS watchdogs to 220, instead of the 150 it previously targeted.  This is to make tripping less likely with the jackhammering going on next door.  I've also turned off all the oplev damping.

 Saturday's special event of braking up the large concrete pieces in CES bay was un event full.

Attachment 1: dig10d.png
dig10d.png
Attachment 2: P1050740.JPG
P1050740.JPG
  2312   Mon Nov 23 10:11:03 2009 steveUpdatePEMlong term temp fluctuation of the 40m lab

Quote:

This first plot shows the RC temperature channels' performance from 40 days ago, before we disabled the MINCO PID controller. Although RCTEMP is supposed to be the out of loop sensor, what we really care about is the cavity length and so I've plotted the SLOW. To get the SLOW on the same scale, I've multiplied the channel by 10 and then adjusted the offset to get it on the same scale.

 The second plot shows a period after that where there is no temperature control of the can at all. Same gain scaling has been applied to SLOW as above, so that instead of the usual 1 GHz/V this plot shows it in 0.1 GHz/V.

The third plot shows it after the new PID was setup.

Summary: Even though the PID loop has more gain, the true limit to the daily fluctuations in the cavity temperature and the laser frequency are due to the in-loop sensors measuring the wrong thing. i.e. the out-of-loop temperature is too different from the in-loop sensor. This can possibly be cured with better foam and better placement of the temperature sensors. Its possible that we're now just limited by the temperature gradients on the can.

 Here is a 7 years plot of  of the 40m temperature variations.

Attachment 1: 7ytemp.jpg
7ytemp.jpg
  2311   Mon Nov 23 00:46:09 2009 rana, robUpdatePSLISS RIN: Its too high by 10x

This plot shows the RIN as measured by the ISS. Its ~2 x 10^-7, whereas its supposed to be more like 3 x 10^-8.

The ISS has DC coupled RIN channels (with a _F suffix) and AC coupled RIN channels (with a _FW suffix). By using a swept sine, Rob determined that the AC coupled channels have an AC coupling pole at ~80 Hz. The attached plot uses this and then has the overall gain adjusted to match with the _F channels below 10 Hz.

The _F channels can be converted directly into RIN by just dividing the spectra by the mean value of the time series. The dark offset of these channels is small and so this only introduces a ~5-10% calibration error.

Question #1: Why is the RIN so bad? According to the MEDM screen, the photocurrent on the MON/SENS PDs is 1.9/1.3 mA. That's sort of low, but should still allow us to get 5x10^-8 in RIN.

Question #2: Does it make an effect on the current DC Readout work? IF so, should we try to fix up the ISS in a temporary way? Since the in-loop and out-of-loop detectors are completely coherent, all of the noise is likely just unsuppressed noise from the laser. We are unable to increase the gain because of the high frequency noise from the NPRO.

 

Let's remember to replace this ISS with a new one that can drive an AOM. Need a volunteer to get us a new ISS.

 

Attachment 1: Untitled.png
Untitled.png
  2310   Fri Nov 20 17:44:38 2009 JenneUpdateAdaptive FilteringSome svn shenanigans

[Sanjit, Jenne]

Sanjit and I are trying to put names to some signals which exist in SimuLink land, but which don't (yet) exist in EPICS land.  The deelio is that for each of the chosen SEIS signals in the ASS_TOP_PEM screen, the signal is split.  One part of the signal is used to decide how the adaptive filter should look, and the other part is actually used when doing the on-line subtraction.  Previously only the part of the signal which is used to decide on the Adaptive Filter could be seen on the screens, and had names. 

Before touching anything on the Simulink ASS.mdl, I did an svn check in, which put things at revision 36639. 

To try to make the desired signals exist, I put cdsFilt boxes (to create filter modules for each of these signals), and gave each of them a name (kind of like the Neverending Story....once they have a name, they'll exist).  My new names are C1:ASS-TOP_PEM_#_APPLY, which correspond to the previously-existing C1:ASS-TOP_PEM_#_ADPT (these are the ones that are along the top of the ASS_TOP_PEM matrix screen).  This version of the simulink model was checked in, and the svn is now at revision 36640.

We then did some "make clean", "make ass" and "make install-ass" action, and burt restored c1assepics, but nothing seems to be happening.  The screen doesn't have white boxes all over the place, and we didn't get any errors when we did the makes, and I'm sure we burt restored correctly (made sure the ASS GDS screen had a 1 in the lower left box etc), but all the values on the screen are still zero.  

When we ran the ass front end in terminal on the c1ass machine, we did see an error: "Invalid chan num found 2 = 30624" "DAQ init failed -- exiting".  I think this means that we need to have told some file somewhere that I was going to be adding 8 new channels. (maybe an .ini file?) Hopefully the Joe & Peter team can help us out with this, since they've been doing this kind of thing for the new system.

Moral of the story is, the new (non-working) simulink file has been svn checked in as revision 36640, and we're reverting to revision 36639, which was before I touched anything today.

  2309   Fri Nov 20 16:18:56 2009 robConfigurationSUSwatchdog rampdown

I've changed the watchdog rampdown script so it brings the SUS watchdogs to 220, instead of the 150 it previously targeted.  This is to make tripping less likely with the jackhammering going on next door.  I've also turned off all the oplev damping.

  2308   Fri Nov 20 13:54:45 2009 AlbertoOmnistructureEnvironmentNew Paper and Cardboard Recycling Bins Introduced to the 40m

The 40m produces a large amount of paper and cardboard waste. It would be worth it if we disposed those kind of garbages for recycling.

I set up two new garbage bins in the lab: one in the control rooms that adds up to the can/bottle recycling bin, and one other one in the office area, next to the printer for general paper disposal.

People in the lab are strongly invited to make use of the two new garbage bins and recycle their paper and cardboard waste.

Boxes can be larger than the garbage bin, so I'd recommend people to crash them before throwing them into the bin.

DSC_1030.JPG

DSC_1031.JPG

  2307   Fri Nov 20 11:32:48 2009 HaixingUpdateSUSMagnetic levitation

I added an integrator to increase the gain at low frequencies (below 5 Hz). In addition, I increased

the band of the differentiator. The schematics for both integrator and differentiator are the following:

IntDiff.PNG

The magnetic is stably levitated.

S8007340.jpg

I turned off the light to get rid of 60Hz noise on the photodiode. I tried to measured the

open-loop transfer function of this setup, but somehow the SR560 is always saturate

when I injected the signal from SR785, which produces some weird results at

low-frequencies.

 

In addition, I found out that when the light is turned on, the levitation

can be stable even when I inverted the sign of the control loop. The control signal

on the osciloscope is the following:

S8007333.jpg

 

This oscillator is around 120 Hz, which should be  the harmonics of 60 Hz from light pollution.

I am not sure exactly why it is stable when the control-loop sign is flipped. This could

be similar to the Pauli trap in the iron trap, because the coil not only provides a force

but also provides the rigidity. The sign of such rigidity depends on the sign of the control

current. If such oscillating rigidity changes at a frequency much higher than the response

frequency of the magnet, it will stablize  the system simply by significantly increasing

the inertial of the magnet.More investigations are essential to completely understand it.

 

For information about Pauli trap, one can look at the wikipedia:

http://en.wikipedia.org/wiki/Quadrupole_ion_trap

 

 

 

  2306   Fri Nov 20 11:14:22 2009 josephb, alexConfigurationComputerstest points working on megatron and we may have filters with switch outputs built in

Alex tooked at the channel definitions (can be seen in tpchn_C1.par), and noticed the rmid was 0. 

However, we had set in testpoint.par the tst system to C-node1 instead of C-node0.  The final number inf that and the rmid need to be equal.   We have changed this, and the test points appear to be working now.

However, the confusing part is in the tst model, the gds_node_id is set to 1.  Apparently, the model starts counting at 1, while the code starts counting at 0, so when you edit the testpoint.par file by hand, you have to subtract one from whatever you set in the model.

In other news, Alex pointed me at a CDS_PARTS.mdl, filters, "IIR FM with controls".  Its a light green module with 2 inputs and 2 outputs.  While the 2nd set of input and outputs look like they connect to ground, they should be iterpreted by the RCG to do the right thing (although Alex wasn't positive it works, it worth trying it and seeing if the 2nd output corresponds to a usable filter on/off switch to connect to the binary I/O to control analog DW.  However, I'm not sure it has the sophistication to wait for a zero crossing or anything like that - at the moment, it just looks like a simple on/off switch based on what filters are on/off.

  2305   Fri Nov 20 11:01:58 2009 josephb, alexConfigurationComputersWhere to find RFM offsets

Alex checked out the old rts (which he is no longer sure how to compile) from CVS to megatron, to the directory:

/home/controls/cds/rts/

In /home/controls/cds/rts/src/include you can find the various h files used.  Similarly, /fe has the c files.

In the h files, you can work out the memory offset by noting the primary offset in iscNetDsc40m.h

A line like suscomms.pCoilDriver.extData[0] determines an offset to look for.

0x108000 (from suscomms )

Then pCoilDriver.extData[#] determines a further offset.

sizeof(extData[0]) = 8240  (for the 40m - you need to watch the ifdefs, we were looking at the wrong structure for awhile, which was much smaller).

DSC_CD_PPY is the structure you need to look in to find the final offset to add to get any particular channel you want to look at.

The number for ETMX is 8, ETMY 9 (this is in extData), so the extData offset from 0x108000 for ETMY should be 9 * 82400.  These numbers (i.e. 8 =ETMX, 9=ETMY) can be found in losLinux.c in /home/controls/cds/rts/src/fe/40m/.  There's a bunch of #ifdef and #endif which define ETMX, ETMY, RMBS, ITM, etc.  You're looking for the offset in those.

So for ETMY LSC channel (which is a double) you add 0x108000 (a hex number) + (9 * 82400 + 24) (not in hex, need to convert) to get the final value of 0x11a160 (in hex).

-----------

A useful program to interact with the RFM network can be found on fb40m.  If you log in and go to:

/usr/install/rfm2g_solaris/vmipci/sw-rfm2g-abc-005/util/diag

you can then run rfm2g_util, give it a 3, then type help.

You can use this to read data.  Just type help read.  We had played around with some offsets and various channels until we were sure we had the offsets right.  For example, we fixed an offset into the ETMY LSC input, and saw the corresponding memory location change to that value.  This utility may also be useful for when we do the RFM test to check the integrity of the ring, as there are some diagnostic options available inside it.

  2304   Fri Nov 20 00:18:45 2009 ranaSummaryCamerasVideo MUX Selection Wiki page

Steve is summarizing the Video Matrix choices into this Wiki page:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/VideoMUX

Requirements:

Price: < 5k$

Control: RS-232 and Ethernet

Interface: BNC (Composite Video)

Please check into the page on Monday for a final list of choices and add comments to the wiki page.

  2303   Thu Nov 19 18:49:55 2009 AlbertoConfigurationelogElog debugging output - Down time programmed today to make changes

Quote:

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

 I tried applying the changes but they didn't work. It seems that nodus doesn't like the command syntax.

I have to go through the problem...

The elog is up again.

  2302   Thu Nov 19 16:04:48 2009 AlbertoConfigurationelogElog debugging output - Down time programmed today to make changes

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

  2301   Thu Nov 19 11:33:15 2009 josephbConfigurationComputersMegatron

I tried rebooting megatron, to see if that might help, but everything still acts the same. 

I tried using daqconfig and changed channels from deactiveated to activated.  I learned by activating them all, that the daq can't handle that, and eventually aborts from an assert checking a buffer size being too small.  I also tried activating 2 and looking at those channels, and it looks like the _DAQ versions of those channels work, or at least I get 0's out of C1:TST-ETMY_ASCPIT_OUT_DAQ (which is set in C1TST.ini file).

I've added the SENSOR channels back to the /csv/cds/caltech/chans/daq/C1TST.ini file, and those are again working in data viewer.

At this point, I'm leaving megatron roughly in the same state as last night, and am going to wait on a response from Alex.

  2300   Thu Nov 19 10:19:04 2009 josephbUpdateComputersMegatron tst status

I did a full make clean and make uninstall-daq-tst, then rebuilt it.  I copied a good version of filters to C1TST.txt in /cvs/cds/caltech/chans/ as well as a good copy of screens to /cvs/cds/caltech/medm/c1/tst/.

Test points still appear to be broken.  Although for a single measurement in dtt, I was somehow able to start, although the output in the results page didn't seem to have any actual data in the plots, so I'm not sure what happened there - after that it just said unable to select test points.  It now says that when starting up as well.  The tst channels are the only ones showing up.  However, the 1k channels seem to have disappeared from Data Viewer, and now only 16k channels are selectable, but they don't actually work.  I'm not actually sure where the 1k channels were coming from earlier now that I think about it.  They were listed like C1:TST-ETMY-SENSOR_UL and so forth.

RA: Koji and I added the SENSOR channels by hand to the .ini file last night so that we could have data stored in the frames ala c1susvme1, etc.

  2299   Thu Nov 19 09:55:41 2009 josephbUpdateComputersTrying to get testpoints on megatron

This is a continuation from last night, where Peter, Koji, and I were trying to get test point channels working on megatron and with the TST module.

Things we noticed last night:

We could run starttst, and ./daqd -c daqdrc, which allowed us to get some channels in dataviewer.  The default 1k channel selection works, but none of the testpoints do. 

However, awgtpman -s tst does appear in the processes running list.

The error we get from dataviewer is:

Server error 861: unable to create thread
Server error 23328: unknown error
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Going to DTT, it starts with no errors in this configuration.  Initially it listed both MDC and TST channels.  However, as a test, I moved the tpchn_C4.par , tpchn_M4.par and tpchn_M5.par files to the directory backup, in /cvs/cds/caltech/target/gds/param.  This caused only the TST channels to show up (which is what we want when not running the mdc module.

We had changed the daqdrc file in /cvs/cds/caltech/target/fb, several times to get to this state.  According to the directions in the RCG manual written by Rolf, we're supposed to "set cit_40m=1" in the daqdrc file, but it was commented out.  However, when we uncommented it, it started causing errors on dtt startup, so we put it back.  We also tried adding lines:

set dcu_rate 13 = 16384;
set dcu_rate 14 = 16384;

But this didn't seem to help.  The reason we did this is we noticed dcuid = 13 and dcuid = 14 in the /cvs/cds/caltech/target/gds/param/tpchn_C1.par file.  We also edited the testpoint.par file so that it correctly corresponded to the tst module, and not the mdc and mdp modules.  We basically set:

[C-node1]
hostname=192.168.1.2
system=tst

in that file, and commented everything else out.

At this point, given all the things we've changed, I'm going to try a rebuild of the tst and daq and see if that solves things.

 

  2298   Thu Nov 19 09:48:54 2009 steveUpdatePEMconstruction effect

8 days plot: Thurdsay, Friday, Sat and Sun without construction

Attachment 1: varseism.png
varseism.png
  2297   Thu Nov 19 09:25:19 2009 steveUpdateMOPAwater was added to the laser chiller

I added ~500 cc of distilled water to the laser chiller yesterday.

Attachment 1: htempwtr.png
htempwtr.png
  2296   Thu Nov 19 08:53:12 2009 peteFrogsEnvironmentdiesel fumes

 Instead of doing RCG stuff, I went to Millikan to work on data analysis as I couldn't stand the fumes from the construction.  (this morning, 8am) 

  2295   Wed Nov 18 22:38:17 2009 KojiUpdateElectronicsmulti-resonant EOM --- EOM characterization ---

How can I get those values from the figure?

Quote:

But indeed it has lead inductance of 12nH, resistance of 0.74[Ohm], and parasitic capacitance of 5.5pF. 

 

  2294   Wed Nov 18 16:58:36 2009 kiwamuUpdateElectronicsmulti-resonant EOM --- EOM characterization ---

In designing the whole circuit it is better to know the characteristic of the EOM.

I made impedance measurement with the EOM (New Focus model 4064) and I found it has capacitance of 10pF.

This is good agreement with the data sheet which says "5-10pF".

The measured plot is attached below. For comparison there also plotted "open" and "10pF mica".

In the interested band( from 1MHz to 100MHz), EOM looks just a capacitor.

But indeed it has lead inductance of 12nH, resistance of 0.74[Ohm], and parasitic capacitance of 5.5pF.

In some case we have to take account of those parasites in designing.

EOM_impedance.png

 

  2293   Wed Nov 18 16:24:25 2009 peteConfigurationSUSETMY suspension conencted to megatron ADC/DAC

/cvs/cds/caltech/target/fb/daqd -c daqdrc

This starts the FB.

Now the dataviewer and DTT work!

Quote:

0) Now the connection for the ETMY suspension was restored in a usual state. It damps well.

1) I thought it would be nice to have dataviewer and DTT working.
   So far, I could not figure out how to run daqd and tpman.
   - I tried to configure
    /cvs/cds/caltech/target/fb/daqdrc
    /cvs/cds/caltech/target/fb/master
    /cvs/cds/caltech/chans/daq/C1TST.ini
(via daqconfig)

   - I also looked at
    /cvs/cds/caltech/targetgds/param/tpchn_C1.par
   but I don't understand how it works. The entries have dcuids of 13 and 14 although C1TST has dcuid of 10.
   The file is unmodified.

   I will try it later when I got a help of the experts.

2) Anyway, I went ahead. I tried to excite suspension by putting some offset.

It seems to have no DAC output. I checked the timing signal. It seems that looks wrong clock.

   I looked at DAC output by putting 5000,10000,15000,20000,25000cnt to UL/UR/LR/LL/SD coils.
   I could not find any voltage out of the DAC in any channels.

   Then, I checked the timing signal. This clock seems to have wrong frequency.
   What we are using now is a clock with +/-4V@4MHz. (Differential)
   Maybe 4194304Hz (=2^22Hz)?

   I went to 1Y3 and checked the timing signal for 16K. This was +/-4V@16kHz. (Diffrential)

   The possible solution would be
   - bring a function generator at the end and try to input a single end 4V clock.
   - stretch a cable from 1Y3 to 1Y9. (2pin lemo)

Quote:

I have connected ETMY sus electronics to megatron ADC/DAC.
We continue this state until 15:00 of today.

 

 

  2292   Wed Nov 18 14:55:59 2009 kiwamuUpdateElectronicsmulti-resonant EOM --- circuit design ----

The circuit design of multi-resonant EOM have proceeded.

By using numerical method, I found the some best choice of the parameters (capacitors and inductors).

In fact there are 6 parameters (Lp, L1, L2, Cp, C1, C2) in the circuit to be determined.

whole_circuit.png

In general the less parameter gives the less calculation time with performing the numerical analysis. Of course it looks 6 parameters are little bit large number.

In order to reduce the arbitrary parameters, I put 4 boundary conditions.

Each boundary conditions fixed resonant peaks and valleys; first peak=11MHz, third peak=55MHz, first valley=19MHz, second valley=44MHz.

designed.png

So now the remaining arbitrary parameters successfully get reduced to 2. Only we have to do is optimize the second peak as it to be 29.5MHz.

Then I take C1 and C2 as free parameters seeing how the second peak agree with 29.5MHz by changing the value of the C1 and C2.

mont.png

the red color represents the good agreement with 29.5MHz, in contrast blue contour represents the bad.

 You can see some best choice along the yellow belt. Now what we should do is to examine some of that and to select one of those.

  2291   Wed Nov 18 12:33:30 2009 Koji, josephbConfigurationSUSETMY suspension conencted to megatron ADC/DAC

Hurraaaah!
We've got the damping of the suspension.
The Oplev loops has also worked!

The DAC channnel swapping was the last key!

DataViewer snapshot to show the damping against an artificial excitation was attached

Quote:

Quote:

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

 

It appears the front panel for the DAC board is mis-labeled.  Channels 1-8 are in fact 9-16, and 9-16 are the ones labeled 1-8.  We have put on new labels to reduce confusion in the future.

 

Attachment 1: Untitled.png
Untitled.png
  2290   Wed Nov 18 11:27:33 2009 Koji, josephbConfigurationSUSETMY suspension conencted to megatron ADC/DAC

Quote:

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

 

It appears the front panel for the DAC board is mis-labeled.  Channels 1-8 are in fact 9-16, and 9-16 are the ones labeled 1-8.  We have put on new labels to reduce confusion in the future.

  2289   Wed Nov 18 01:12:15 2009 ranaUpdatePEMseismometers were not saturating during Halloween weekend
Attachment 1: Untitled.png
Untitled.png
  2288   Wed Nov 18 00:38:33 2009 ranaSummaryElectronicsVoltage Noise of the SR560's OUTPUTs (the back panel)

I've measured the voltage noise of the SR560's lead acid battery outputs; they're not so bad.

Steve ordered us some replacement lead-acid batteries for our battery powered pre-amps (SR560). In the unit he replaced, I measured the noise using the following setup:

SR560                              Busby Box

(+12V/GND) -------------AC Input      Out  ----------------   SR785

The SR785 was DC coupled and auto-ranged. The input noise of the SR785 was measured via 50 Ohm term to be at least 10x less than the SR560's noise at all frequencies.

sr560.png

Its clear that this measurement was spoiled by the low frequency noise of the Busby box below 10 Hz. Needs a better pre-amp.

  2287   Tue Nov 17 21:21:30 2009 robUpdateSUSETMY UL OSEM

Had been disconnected for about two weeks.  I found a partially seated 4-pin LEMO cable coming from the OSEM PD interface board. 

  2286   Tue Nov 17 21:10:35 2009 ranaSummaryElectronicsBusby Low Noise Box: Photos and Upgrades

IMG_0217.JPG

It looked like the Busby Low Noise Box had too much low frequency noise and so I upgraded it. Here is a photo of the inside - I have changed out the 0.8 uF AC coupling cap with a big, white, 20 uF one I found on Rob's desk.

The Busby Box is still working well. The 9V batteries have only run down to 7.8V. The original designer also put a spare AD743 (ultra low current FET amp) and a OP27 (best for ~kOhm source impedances) in there.

Here's the noise after the fix. There's no change in the DC noise, but the AC noise is much lower than before:

busby-noise.png

I think that the AC coupled noise is higher because we are seeing the current noise of the opamp. In the DC coupled case, the impedance to ground from the input pins of the opamp is very low and so the current noise is irrelevant.

The change I implemented, puts in a corner frequency of fc = 1/2/pi/R/C = 1/2/pi/10e3/20e-6 = 0.8 Hz.

Overall, the box is pretty good. Not great in terms of current noise and so it misses getting an A+. But its easily a solid A-.

  2285   Tue Nov 17 21:10:30 2009 KojiConfigurationSUSETMY suspension conencted to megatron ADC/DAC

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

  2284   Tue Nov 17 21:09:17 2009 Jenne, ranaUpdateGeneralLittle Thorlabs Photodiode

[Rana, Jenne]

We opened up the little Thorlabs battery operated PD to see what was inside.  Rana took some pictures, and I drew a schematic (attached).  It's just a diode, biased with a battery (albeit a crazy 22.5V battery).

---------------
Comment by KA: PD is Hamamatsu S1223-01 Si PIN diode.


What a crazy battery. The main point is that it looks like this can be used for reasonable purposes: uses a load resistor on the BNC connector and you can use some pre-amp (e.g. Busby box or SR560) to have a low noise PD readout. You can also use the SR560 in its A-B mode as an 'opamp'. Ground the A input and the use a pole at 1 Hz and make the Output go into the B input through some large series resistor. The BNC from the PD gets Teed into the B input as well.

Then this becomes a transimpedance circuit readout of the diode, using the current noise of the SR560 as the limit.

Attachment 1: ThorlabsPD.png
ThorlabsPD.png
  2283   Tue Nov 17 15:54:34 2009 ranaSummaryPEM40 days of weather

the inside temperature is alarming at the red level today - should check if the HIHI value is set correctly

Attachment 1: Untitled.pdf
Untitled.pdf
  2282   Tue Nov 17 15:23:06 2009 KojiConfigurationSUSETMY suspension conencted to megatron ADC/DAC

OK. Now, Timing/ADC/DAC are working. It's almost there.

1) As a temporaly clock, I put a function generator at the back side of the ETMY.
Set it to the rectangular +/-4V@16384Hz. Connect it to D060064 PCIX Timing Interface Board in the IO Chasis.
That is a line receiver to feed the TTL signal into ADCs/DACs.

I confirmed the actual sampling clock is supplied to the ADC/DAC boards by looking at the SMB output of the D060064.

2) Restarted the realtime code.

3) I looked at DAC output by putting 5000,10000,15000,20000,25000cnt to UL/UR/LR/LL/SD coils again.
Yes! I could see the DAC channels are putting DC voltages.

4) Then I connected DAC CH0 to ADC CH0 using SCSI breaking up boards.
Yes! I could see the coil output switching change the ADC counts!

Now, we are ready to see the suspension damped. Check it out.

  2281   Tue Nov 17 13:39:37 2009 KojiConfigurationSUSETMY suspension conencted to megatron ADC/DAC

0) Now the connection for the ETMY suspension was restored in a usual state. It damps well.

1) I thought it would be nice to have dataviewer and DTT working.
   So far, I could not figure out how to run daqd and tpman.
   - I tried to configure
    /cvs/cds/caltech/target/fb/daqdrc
    /cvs/cds/caltech/target/fb/master
    /cvs/cds/caltech/chans/daq/C1TST.ini
(via daqconfig)

   - I also looked at
    /cvs/cds/caltech/targetgds/param/tpchn_C1.par
   but I don't understand how it works. The entries have dcuids of 13 and 14 although C1TST has dcuid of 10.
   The file is unmodified.

   I will try it later when I got a help of the experts.

2) Anyway, I went ahead. I tried to excite suspension by putting some offset.

It seems to have no DAC output. I checked the timing signal. It seems that looks wrong clock.

   I looked at DAC output by putting 5000,10000,15000,20000,25000cnt to UL/UR/LR/LL/SD coils.
   I could not find any voltage out of the DAC in any channels.

   Then, I checked the timing signal. This clock seems to have wrong frequency.
   What we are using now is a clock with +/-4V@4MHz. (Differential)
   Maybe 4194304Hz (=2^22Hz)?

   I went to 1Y3 and checked the timing signal for 16K. This was +/-4V@16kHz. (Diffrential)

   The possible solution would be
   - bring a function generator at the end and try to input a single end 4V clock.
   - stretch a cable from 1Y3 to 1Y9. (2pin lemo)

Quote:

I have connected ETMY sus electronics to megatron ADC/DAC.
We continue this state until 15:00 of today.

 

  2280   Tue Nov 17 11:09:43 2009 KojiConfigurationSUSETMY suspension conencted to megatron ADC/DAC

I have connected ETMY sus electronics to megatron ADC/DAC.
We continue this state until 15:00 of today. (Restored 13:00)

  2279   Tue Nov 17 10:09:57 2009 josephbUpdateEnvironmentFumes

The smell of diesel is particularly bad this morning.  Its concentrated enough to be causing me a headache.  I'm heading off to Millikan and will be working remotely on Megatron.

  2278   Tue Nov 17 00:42:12 2009 KojiUpdateComputersUpdated wiki with RCG instructions/tips

Dmass, Joe, Koji


A puzzle has been solved: Dmass gave us a great tip

"The RGC code does not work unless the name of the mdl file (simulink model) matches to the model name "

The model name is written in the second line. This is automatically modified if the mdl file is saved from simulink.
But we copied the model by using "cp" command. This prevent from the TST model working!

megatron:simLink>head tst.mdl
Model {
  Name                    "tst"
  Version                 7.3
  MdlSubVersion           0

...
...
...

This explained why the AAA model worked when the DAC block has been copied from the other model.
This was not because of the ADC block but the saving model fixed the model name mismatch!


Now our current working model is "C1TST". Most of the functionalities have been implemented now:

  • The simulink model has been modified so that some of the functionalities can be accomodated, such as LSC/ASC PIT/ASC YAW.
  • Some filter names are fixed so as to inherit the previous naming conventions.
  • The SUS-ETMY epics screen was modified to fit to the new channel names, the filter topologies, and the matrices.
  • The chans file was constructed so that the conventional filter coefficients are inherited.
  • All of the gains, filter SWs, matrix elements have been set accordingly to the current ETMY settings.
  • burt snapshot has been taken: /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap
    burtrb -f /cvs/cds/caltech/target/c1tstepics/autoBurt.req -o controls_1091117_024223_0.snap -l /tmp/controls_1091117_024215_0.read.log -v

What to do next:

  • Revisit Oplev model so that it accomodates a power normalization functionality.
  • ETMY QPD model is also missing!
  • Clean up mdl file using subsystem grouping
  • Check consistency of the whitening/dewhitening switches.
  • Connect ADC/DAC to megatron
  • Test of the controllability
  • BTW, what is happened to BIO?
  • Implementation of the RFM card

Directories and the files:

  • The .mdl file is backed up as
    /home/controls/cds/advLigo/src/epics/simLink/tst.mdl.20091116_2100

  • The default screens built by "make" is installed in
    /cvs/cds/caltech/medm/c1/tst/
    They are continuously overridden by the further building of the models.

  • The custom-built medm screens are stored in
    /cvs/cds/caltech/medm/c1/tst/CustomAdls/

    The backup is
    /cvs/cds/caltech/medm/c1/tst/CustomAdls/CustomAdls.111609_2300/

  • The custom-built chans file is
    /cvs/cds/caltech/chans/C1TST.txt

    The backup is
    /cvs/cds/caltech/chans/C1TST.111609

  • burt snap shot file
    /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap
  2277   Mon Nov 16 17:35:59 2009 kiwamuUpdateLSCOMC-LSC timing get synchronized !

An interesting thing was happened in the OMC-LSC timing clock.

Right now the clock of the OMC and the LSC are completely synchronized.

 The trend data is shown below. At the first two measurements (Oct.27 and Nov.1),  LSC had constant retarded time of 3Ts (~92usec.).

The last measurement, on Nov.15, number of shifts goes to zero, this means there are no retarded time.

Also the variance between the two signal gets zero, so I conclude the OMC and the LSC are now completely synchronized.

The measurement on Nov.8 is somehow meaningless, I guess the measurement did not run correctly by an influence from megatron(?)

 

OMC-LSC.png

 

  2276   Mon Nov 16 17:24:28 2009 josephbConfigurationComputersCamera medm functionality improved

Currently the Camera medm screen (now available from the sitemap), includes a server and client script buttons.  The server has two options.  One which starts a server, the second which (for the moment) kills all copies of the server running on Ottavia.  The client button simply starts a video screen with the camera image.  The slider on this screen changes the exposure level.  The snap shot button saves a jpeg image in the /cvs/cds/caltech/cam/c1asport directory with a date and time stamp on it (up to the second).  For the moment, these buttons only work on Linux machines.

All channels were added to C0EDCU.ini, and should be being recorded for long term viewing.

Feel free to play around with it, break it, and let me know how it works (or doesn't).

  2275   Mon Nov 16 15:58:02 2009 josephbConfigurationGeneralAdded Gige camera to AP table, added some screens

I placed a GC750 gige camera looking at a pickoff of the AS port, basically next to the analog camera, on the AP table.

I've modified the main sitemap to include a CAM button, for the digital cameras.  There's a half done screen associated with it.  At the moment, it reports on the X and Y center of mass calculation, the exposure setting, and displays a little graph with a dot indicating the COM of mass location.  Currently this screen is associated a GC750 camera looking at pickoff of the AS port.  I'm having some issues with getting shell scripts to run from it, as well as a slider having limits other than 0 and 0.

  2274   Mon Nov 16 15:18:10 2009 haixingUpdateSUSStable magnetic levitation without eddy-current damping

By including a differentiator from 10 Hz to 50 Hz, we increase the phase margin and the resulting

magnetic levitation system is stable even without the help of eddy-current damping.

The new block diagram for the system is the following:

 block_diagram_new.png

Here the eddy-current damping component is removed and we add an additional differential

circuit with an operational amplifier OP27G.

In addition, we place the Hall sensor below the magnet to minimize the coupling between

the coil and the Hall sensor.

The resulting levitation system is shown by the figure below:

mag_levi_new.jpg

  2273   Mon Nov 16 15:13:25 2009 josephbUpdateComputersezcaread updated to Yoichi style ezcawrite

In order to get the gige camera code running robustly here at the 40m, I created a "Yoichi style" ezcaread, which is now the default, while the original ezcaread is located in ezcaread.bin.  This tries 5 times before failing out of a read attempt.

  2272   Mon Nov 16 09:37:41 2009 steveUpdatePEMconstruction is getting noisier

 

ATM1: Seismometers are saturating, suspensions are OK

Atm2 : activity next door,  diesel Backhoe and diesel concrete cutter are running

Atm3: CES exhaust fans output  is pick up by 40M-Annex-North AC unit  intake. The 40m office room has some diesel smell...........see # 2377

Attachment 1: 4hces.png
4hces.png
Attachment 2: P1050734.JPG
P1050734.JPG
Attachment 3: P1050736.JPG
P1050736.JPG
ELOG V3.1.3-