40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 138 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  14931   Thu Oct 3 14:32:37 2019 ranaUpdateGeneralMake the Jenne-laser setup fiber-coupled

I'm curious to see if we really need the 1611, or if we can calibrate the diode laser vs. the 1611 one time and then just use that calibration to get the absolute cal for the DUT.

  14932   Thu Oct 3 14:54:33 2019 KojiUpdateGeneralMake the Jenne-laser setup fiber-coupled

I'm afraid that the RF modualtion of the laser is nonlinear and the electrical and optical resoponse is dependent on the LD pumping current and RF input power. So I feel safe if we keep the reference PD. Of course, this is my feeling and it should be quantitatively tested.

  14934   Thu Oct 3 21:05:04 2019 aaronUpdateGeneralMake the Jenne-laser setup fiber-coupled

I measured the RF response of the fiber-coupled NewFocus 1611, calibrating out the cable delay. The laser current was set to 20.0 mA, and the RF power going into the splitter was -10 dBm. The DC voltage was 1.87 V, and Gautam and I measured the power from the fiber at 344uW.

Something still looks very wrong -- the PD is supposed to be flat out to 1GHz, and physical units pending, need food.

Attachment 1: PD_response.pdf
PD_response.pdf
  14936   Thu Oct 3 23:15:39 2019 KojiUpdateGeneralMake the Jenne-laser setup fiber-coupled

The 1GHz PD has a bit more flat response, but the laser and the driving network have more frequency dependence as you saw.

  14937   Fri Oct 4 00:30:31 2019 gautamUpdateGeneralMake the Jenne-laser setup fiber-coupled

I think the metric of interest here is the consistency of the AC transimpedance of the proposed new "Reference PD" (= fiber coupled NF1611) vs the old reference (free space NF1611), since everything will be calibrated against that.

Quote:

Something still looks very wrong -- the PD is supposed to be flat out to 1GHz, and physical units pending, need food.

  14940   Fri Oct 4 14:25:59 2019 aaronUpdateGeneralMake the Jenne-laser setup fiber-coupled

Summary:

The fiber-coupled PD seems to have a factor of ~1.5 difference in responsivity compared to the free-space PD. There are some differences in the two ways I made the measurement that I don't yet understand.

Details

I measured relative responsivities of the fiber and free coupled NewFocus 1611 PDs (scaled by the Jenne AM transfer function).

I made the measurement in two ways, see attachment threeIn attachment oneI show the response for separately measuring the two PDs relative to a pickoff of the source (two-port thru calibration). In attachment two I measure the relative responses directly, without picking off a reference (three-port calibration). I scaled the transfer functions by their DC voltages; both PDs have transimpedances of 700 V/A.

However, there are some clear differences in the response (overall factor of 0.5dB offset that may be explained by a miscalibrated DC level; apparent periodicity in attachment 1) that I don't yet understand.The free path of the non-fiber PD is ~5-6 inches, which accounts for the ~45 degrees of phase advance of the fiber relative to free coupled PD signal. (12.7cm / (c / 300 MHz) * 360 degrees ~ 45 degrees)

I didn't find Agilent's manual very helpful for learning about the available calibration schemes, and didn't find a resource online that I liked -- is there a good one?
I think I want to characterize the WFS heads treating the DUT as a three-port device (AM in, ref PD, WFS segment PD).
Attachment 1: PD_norm.pdf
PD_norm.pdf
Attachment 2: PD_AB.pdf
PD_AB.pdf
Attachment 3: JenneAM_fiberPD_cals.pdf
JenneAM_fiberPD_cals.pdf
  13120   Sat Jul 15 16:19:00 2017 gautamUpdateCamerasMakeshift PyPylon

Some days ago, I stumbled upon this github page, by a grad student at KIT who developed this code as he was working with Basler GigE cameras. Since we are having trouble installing SnapPy, I figured I'd give this package a try. Installation was very easy, took me ~10mins, and while there isn't great documentation, basic use is very easy - for instance, I was able to adjust the exposure time, and capture an image, all from Pianosa. The attached is some kind of in-built function rendering of the captured image - it is a piece of paper with some scribbles on it near Jigyasa's BRDF measurement setup on the SP table, but it should be straightforward to export the images in any format we like. I believe the axes are pixel indices.

Of course this is only a temporary solution as I don't know if this package will be amenable to interfacing with EPICS servers etc, but seems like a useful tool to have while we figure out how to get SnapPy working. For instance, the HDR image capture routine can now be written entirely as a Python script, and executed via an MEDM button or something.

A rudimentary example file can be found at /opt/rtcds/caltech/c1/scripts/GigE/PyPylon/examples - some of the dictionary keywords to access various properties of the camera (e.g. Exposure time) are different, but these are easy enough to figure out.

 

Attachment 1: pyPylon_test.png
pyPylon_test.png
  1132   Thu Nov 13 11:33:25 2008 AlbertoHowToTreasureMaking (good) Matlab figures
Just a little summary of some useful ways to change plot settings in Matlab that I wanted to share and remember for the future:

http://saig.phys.ualberta.ca/toolbox/Matlab/making_figures.html
  175   Thu Dec 6 18:11:15 2007 robHowToComputer Scripts / ProgramsMaking DMF monitors

I was able to use the matlab compiler to compile a version of the linetracker written by Rana, and run the compiled version on mafalda.

I believe I made the necessary edits to our mDV config file so that it should be easy for others to follow these steps:

1) Write the DMF routine you want, as a matlab function (not a script).

2) If it runs correctly in matlab, then from the matlab command line compile
it using the -m flag (i.e., mcc -m myfun.m). You should run the
compiler from the directory where you want the executable to end up (don't use the mDV/extra
directory so it doesn't get all cluttered).

3) prior to running the resulting executable (which should be called simply myfun),
prepend the directories
/cvs/cds/caltech/apps/linux/matlab/bin/glnx86
/cvs/cds/caltech/apps/linux/matlab/sys/os/glnx86/

to the LD_LIBRARY_PATH enviroment variable. These directories must be prepended as the
versions that already exist in /usr/lib don't work; I'm loathe to do this in the cshrc.40m
for fear of later conflicts, so it will need to be done in some sort of shell script which
calls the matlab executable.
  14832   Tue Aug 6 14:55:23 2019 gautamUpdateCDSMaking Matlab R2015b the default

ML2013 is unable to open Simulink on any of the workstations. We decided to make the default version of Matlab R2015b (the default of the version of RCG we are using).

I commenced the procedure of the migration, starting with making a tagged commit of the current running simulink models. A local backup was also made, plus we have the usual chiara-based backup so I think we're in good hands.

Currently the branch and tag are protected - once we verify that everything works as expected post migration, I will open it up. I changed the directory structure of the models, need to confirm that the rtcds compilers don't have any hardcoded paths which may break due to my change.

The symlink to Matlab R2013 was deleted and a new symlink to R2015b was made. I activated the license using the Caltech campus license. Now running matlab from shell starts up R2015b yes. Simulink even works 😲 .

Attachment 1: ML2015b.png
ML2015b.png
  13845   Tue May 15 20:51:27 2018 gautamConfigurationElectronicsMaking PLL setup more permanent

[jon, steve, gautam]

Some points which Jon will elaborate upon (and put photos of) in his detailed elog about this setup:

  • PLL electronics (mixer, coupler, ZFL500HLN amplifier and DC power supply for the beatnote, SR560 servo) all reside on the newly installed lower level PSL shelf.
  • Cross connect channel C1:PSL-126MOPA_126CURADJ hijacked for remote temperature control of the AUX NPRO. Note that shield of front panel BNC is ground and so even though the manual says the controller accepts +/-10V, this is not a differential input. BNC cable was routed from cross connect to PSL enclosure, MEDM slider will be setup.
  • There was an SMA cable running from the VEA to the control room which we decided to use for monitoring of the beatnote amplitude on the control room analyzer. Yesterday, Steve and I routed the end of this inside the VEA, near 1X2 originally, to inside the PSL table where it is hooked up to the (20dB) coupled amplifier output. This required some work on the cable tray, we were careful but in case there is some wonkiness in some signals, perhaps this work is to blame.

We are now in a state where the PLL can be locked remotely from the control room by tweaking the AUX laser temperature laugh. Tomorrow, Keerthana will work on getting Craig's/Johannes' Digital Frequency Counter script working here, I think we can easily implement a PLL autolocker if we have some diagostic that tells us if the PLL us locked or not.


Steve informed me that there is an acoustic hum inside the PSL enclosure which wasn't there before. Indeed, it is at ~295Hz, and is from the Bench power supply used to power the ZFL500HLN amplifier. This will have to go...

  5558   Tue Sep 27 15:33:03 2011 JenneUpdateComputersMaking models, wreaking havoc

[Jenne, Mirko, Den]

We have entered into an adventure in model compiling.  What follows is a stream-of-consciousness report of what the hell we're doing, so Jamie can figure it out and fix it if everything goes to hell.

Note that for the first part of things, we have used a new version of the Adaptive XFCODE, which Mirko and Den modified last night to be able to handle multiple control signal inputs.  

On c1lsc, make uninstall-daq-c1oaf, make clean-c1oaf, make c1oaf.

***ERROR: The following IPCx RECEIVER module(s) not found in the file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc:

                C1:RFM_OAF_MCL

On c1sus, make uninstall-daq-c1sus, make clean-c1sus, make c1sus.  (This was an accident.  I should have been making c1rfm.  Oops.)  Then make install-c1sus.  It looks like this automatically did make install-daq-c1sus and make install-screens-c1sus, so I'm not doing those. 

On c1sus, make uninstall-daq-c1rfm, make clean-c1rfm, make c1rfm.

***ERROR: The following IPCx RECEIVER module(s) not found in the file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc:

                C1:IOO-RFM_MCL


On c1ioo, make uninstall-daq-c1ioo, make clean-c1ioo, make c1ioo.  No errors.

On c1lsc, make c1oaf.  Here's some of the ouptut, with some of the error stuff:

: warning: ISO C90 forbids mixed declarations and code
/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../controller.c:2954: warning: ISO C90 forbids mixed declarations and code
make[3]: *** [/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/c1oaffe.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf] Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.34.1-cs'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf'
make: *** [c1oaf] Error 2

Again on c1lsc, make clean-c1oaf, make c1oaf.  Here are some things:

Warning:  variable "sysnum" is used but not declared.

In file included from build/c1oafepics/c1oaf.i:38:
src/include/fmReadCoeff.h:4:1: warning: "NO_FM10GEN_C_CODE" redefined
<command-line>: warning: this is the location of the previous definition

build/c1oafepics/c1oaf.i:5156: warning: passing argument 2 of 'strcpy' discards qualifiers from pointer target type
/usr/include/string.h:127: note: expected 'const char * __restrict__' but argument is of type 'volatile char *'

/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../../include/drv/inputFilterModule1.h:5: note: expected 'double *' but argument is of type 'long unsigned int *'

/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../controller.c:2780: warning: ISO C90 forbids mixed declarations and code

make[3]: *** [/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/c1oaffe.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf] Error 2
make[1]: *** [default] Error 2
make: *** [c1oaf] Error 2

Again, on c1lsc, make clean-c1oaf, make c1oaf.  More errors, pretty similar.  Then we changed the name of the adaptive filtering code, so maybe it will work now?  We had called the block "TOP_XFCODE", but that was the name of the old .c code.  The block used to be called "XFCODE", in a subsystem "TOP".  So now we named the .c code "ADAPT_XFCODE" since the block is "XFCODE", and the subsystem is "TOP".

Again, on c1lsc, make clean-c1oaf, make c1oaf.  Errors, they look the same.

Mirko is now modifying c1oaf.mdl to look more like the old version, with only one control signal input, so that we can use the old XFCODE that has been around for years.

First, we completely took out the .c code entirely.  Now the c1oaf.mdl is just signals and matricies, no c-code is called.  We did make clean-c1oaf, make c1oaf, and pretty much all of the same errors are present.
 

We took out the buses, and did make clean-c1oaf, make c1oaf, and we got a whole lot of warnings, but no "Error 2"'s.  This seems good.  We're going to try replacing those buses with Muxes, and see how that goes.

Now we're going to try to install the c1oaf, because maybe all the errors and shit we're seeing is just useless crap, and there aren't actually problems...here we go!

That seemed to work, and the c1oaf model on the GDS status screen seems happy.  Numbers are moving around, which is my only current diagnostic.

Okay, now Mirko is going back to the full, new c1oaf, but replacing the Buses with Muxes. 

Did a make clean-c1oaf, make c1oaf, got errors again.

Once again removed the .c code.  Just put in a matrix instead. Did make clean-c1oaf, make c1oaf.  No errors. 

Den did a reorganization of the .c code, and we put it back in to the simulink model.  Trying again the making stuff.  Fail..Basically the same errors as before.

Next up:  Putting in .c-code, but something which basically does nothing.  Just defines all the outs as zeros.  Make stuff.  Still had problems, same errors.  Grrrr, argh. 

Found the RCG manual:  T080135-v4.  In it, when talking about including c-code, it had an example of totally simple code.  We tried out their version of simple code, and it worked.  No errors!  Now to figure out what is same and different between our simple code and theirs.

 PUT THE RIGHT STUFF in the Block Properties for the c-code, including name of the .c file, and path to the .c file.  This is critical!!  Now we can make some of our simple versions work, but not all.  We're slowly increasing complexity of our c-code...

 At some point in the last hour, I tried a make install-c1oaf, and then checked the screens, and they all had bad white boxes.  So even though the model seemed to compile (at one point), the channels and screens aren't happy yet.  But that's really a project for after the code compiles happily.

Okay, some progress was made to get the c-code running, and compiling, but it's not all there yet.  We're putting in a simple, useless version of the c-code so we can try compiling everything else.

Everything is compiled, installed, there are no red lights on the GDS_STATUS screen.  All seems okay for locking for tonight.

 

  13013   Thu May 25 16:42:41 2017 jigyasaUpdateComputer Scripts / ProgramsMaking pylon installation on shared directory

I have been working on interfacing with the GigE’s. I went through Joe Be’s paper and the previous elogs and verified that the code files are installed.

I then downloaded and extracted a copy of the Pylon software onto my home directory on Allegra. Gautam helped me find installation instructions on Johannes’ directory so that I could make the installation on the shared directory.

So far , according to instructions, these commands need to be executed so that the installation takes place and the rules for camera permissions are set up.

sudo tar –C /opt/rtcds/caltech/c1/scripts/GigE –xzf pylon SDK*.tar.gz

followed by ./setup-usb.sh

The Pylon viewer can then be accessed with /scripts/GigE/pylon5/bin/PylonViewerApp 

Should I go ahead with the installation in the shared directory?

  13014   Thu May 25 18:37:11 2017 jigyasaUpdateComputer Scripts / ProgramsMaking pylon installation on shared directory

Gautam helped me execute the commands mentioned above and Pylon has now been installed on the shared directory. We extracted the pylon installation from Johannes's directory to the shared drive and executing the command tar –C /opt/rtcds/caltech/c1/scripts/GigE –xzf pylon SDK*.tar.gz created an unzipped pylon5 folder in /scripts. The ./setup-usb.sh set up the udev rules for the GigE.

The installation took place without any errors.

The Pylon viewer app can now be accessed at /opt/rtcds/caltech/c1/scripts/GigE/pylon5/bin followed by ./PylonViewerApp 

Quote:

Should I go ahead with the installation in the shared directory?

 

  976   Mon Sep 22 15:02:45 2008 ranaFrogsTreasureMantis found outside the 40m door at night
Attachment 1: mantis.JPG
mantis.JPG
  5034   Mon Jul 25 23:43:20 2011 ManuelHowToElectronicsManual for 1201 Low Noise Preamplifier

I found the manual for the Low Noise Preamplifier Model 1201 at this link and I attached it.

The one we have in the lab (S/N 48332) miss the battery packs and miss also the remote programming options input/output. Its inside battery compartment is empty and I found 2 unscrewed screws with washers and nuts inside the preamplifier box. The battery cable are disconnected and they have 2 green tape labels (-) and 2 red tape label (+).

 

 

Attachment 1: ITHACO_1201_Instruction_&_Maintenance.pdf
ITHACO_1201_Instruction_&_Maintenance.pdf ITHACO_1201_Instruction_&_Maintenance.pdf ITHACO_1201_Instruction_&_Maintenance.pdf ITHACO_1201_Instruction_&_Maintenance.pdf ITHACO_1201_Instruction_&_Maintenance.pdf ITHACO_1201_Instruction_&_Maintenance.pdf ITHACO_1201_Instruction_&_Maintenance.pdf ITHACO_1201_Instruction_&_Maintenance.pdf
Attachment 2: DSC_3249.png
DSC_3249.png
  14395   Thu Jan 10 11:32:40 2019 ChubUpdateVACManual valve interfaced with CDS

Connected the manual gate valve status indicator to the Acromag box this morning.  Labeled the temporary cable (a 50' 9p DSUB, will order a proper sized cable shortly) and the panel RV2.  

  5050   Wed Jul 27 15:49:56 2011 steveUpdateSAFETYManuel receives safety training

Our surf student Manuel Marchiò received 40m specific safety training today.

Attachment 1: P1080096.JPG
P1080096.JPG
  15743   Mon Dec 21 18:18:03 2020 gautamUpdateCDSMany model changes

The CDS model change required to get the AS WFS signals into the RTCDS system are rather invasive.

  • We use VCS for these models. Linus Torvald may question my taste but I also made local backups of the models, just in case...
  • Particularly, the ADC1 card on c1ioo is completely reconfigured.
  • I also think it's more natural to do all the ASC computations on this machine rather than the c1lsc machine (it is currently done in the c1ass model). So there are many IPC changes as well.
  • I have documented everything carefully, and the compile/install went smoothly.
  • Taking down all the FE servers at 1830 local time
    1. To propagagte the model changes
    2. To make a hardware change in the c1rfm card in the c1ioo machine to configure it as "ROGUE MASTER 0"
    3. To clear the RFM errors we are currently suffering from will require a model reboot anyways.
  • Recovery was completed by 1930 - the RFM errors are also cleared, and now we have a "ROGUE MASTER 👾" on the network. Pretty smooth, no major issues with the CDS part of the procedure to report.
  • The main issue is that in the AA chassis I built, Ch14 (with the first channel as Ch1) has the output saturated to 28V (differential). I'm not sure what kind of overvoltage protection the ADC has - we frequently have the inputs exceed the spec'd +/-20 V (e.g. when the whitening filters are engaged and the cavity is fringing), but pending further investigation, I am removing the SCSI connection from the rear of the AA chassis.

In terms of computational load, the c1ioo model seems to be able to handle the extra load no issues - ~35us/60us per cycle. The RFM model shows no extra computational time

After this work, the IMC locking and POX/POY locking, and dither alignment servos are working okay. So I have some confidence that my invasive work hasn't completely destroyed everything. There is some hardware around the rear of 1X2 that I will clear tomorrow.

Attachment 1: CDSoverview.png
CDSoverview.png
  11479   Wed Aug 5 10:56:07 2015 ericqUpdateCDSMany models crashed

Last night around 1AM, many of the the frontend models crashed due to an ADC timeout. (But none of the IOPs, and all the c1lsc models were fine.)

 
First, on c1sus (Wed Aug  5 00:56:46 PDT 2015)
[1502036.695639] c1rfm: ADC TIMEOUT 0 46281 9 46153
[1502036.945259] c1pem: ADC TIMEOUT 0 56631 55 56695
[1502036.965969] c1mcs: ADC TIMEOUT 1 56706 2 56770
[1502036.965971] c1sus: ADC TIMEOUT 1 56706 2 56770

Then, simultaneously on c1ioo, c1iscex, and c1iscey. (Wed Aug  5 01:10:53 PDT 2015)

[1509007.391124] c1ioo: ADC TIMEOUT 0 46329 57 46201
[1509007.702792] c1als: ADC TIMEOUT 1 63128 24 63192

[2448096.252002] c1scx: ADC TIMEOUT 0 46293 21 46165
[2448096.258001] c1asx: ADC TIMEOUT 0 46669 13 46541

[1674945.583003] c1scy: ADC TIMEOUT 0 46297 25 46169
[1674945.685002] c1tst: ADC TIMEOUT 0 52993 1 52865

I'm still working on getting things back up and running. Just restarting models wasn't working, so I'm trying some soft reboots...


UPDATE: A soft reboot of all frontends seems to have worked,

Attachment 1: crashes.png
crashes.png
  6904   Mon Jul 2 18:28:09 2012 JenneUpdatePhotosMany photos taken

Many photos were taken by many different people....most of the fuzzy ones are by yours truely (doing a reach-around to get to hard-to-reach places), so sorry about that.

I put all the photos from yesterday and today into 6 new albums on Picasa:  https://picasaweb.google.com/foteee

The album titles are generally descriptive, and I threw in a few comments where it seemed prudent.

Big note:  The tip tilt on the ITMX table does, in fact, have the arrow pointing in the correct direction.  Photo is in the TT album from today.

  15011   Mon Nov 4 19:02:25 2019 YehonathanUpdatePSLMapping the PSL electronics

I created a spreadsheet (Attached) by taking Koji's c1psl sheet from slow_channel_list and filtering out the channels that do not need an Acromag. I added in the QPD channels that are relevant to the PSL from the c1iool0 sheet.

I began mapping the PSL related Eurocrates connectors to their respective VME channels starting with the PMC electronics.

I am confused about the TTFSS interface (D040423): While it is a Eurocrate card, in the schematics it seems to have 50 pin connectors.

I found old wiring schematics that might help with identifying the channels once the connector issue is clarified.

 

 

Attachment 1: PSL_Wirings_-_Sheet1_(1).pdf
PSL_Wirings_-_Sheet1_(1).pdf
  15099   Tue Dec 17 00:23:28 2019 YehonathanUpdatePSLMapping the PSL electronics

I added to the PSL wiring list the ioo channels and the laser shutter (See attached pdf for an updated list).

The total channel numbers for now:

ai 57
ao 13
bi 1
bo 36

I counted each mbbo as 1 bo but I am not sure that's correct.

Still need to allocate Acromags.

Attachment 1: PSL_Wirings_-_Sheet1_(2).pdf
PSL_Wirings_-_Sheet1_(2).pdf PSL_Wirings_-_Sheet1_(2).pdf
  15100   Tue Dec 17 18:05:06 2019 YehonathanUpdatePSLMapping the PSL electronics

Updated the channel list (Attached):

1. Removed the MC steering mirror PZT channels

2. Added Sourcing/Sinking column

3. Recounted the mbbos correctly

4. Allocated Acromags:

Model Purpose No. Spare channels
XT1221 ai 7 11
XT1541 ao + src bo 2 9 ao
XT1121 src bo 2 4
XT1121 sink bo 1 4

I think we can start wiring.

Attachment 1: PSL_Wirings_-_Sheet1_(3).pdf
PSL_Wirings_-_Sheet1_(3).pdf PSL_Wirings_-_Sheet1_(3).pdf
  15103   Fri Dec 20 18:33:21 2019 YehonathanUpdatePSLMapping the PSL electronics

Final (hopefully) PSL channel list is attached with allocated Acromag channels. Wiring spreadsheet coming soon.

Current Acromag count:

AI 8
AO 2
BIO 4
Number of channels 8*8+2*8+4*16=144
Number of wires 144*2=288

 

Attachment 1: PSL_Wirings_-_Channel_List.pdf
PSL_Wirings_-_Channel_List.pdf PSL_Wirings_-_Channel_List.pdf PSL_Wirings_-_Channel_List.pdf PSL_Wirings_-_Channel_List.pdf PSL_Wirings_-_Channel_List.pdf
  15104   Mon Dec 23 19:30:20 2019 YehonathanUpdatePSLMapping the PSL electronics

PSL wiring spreadsheet is ready. (But the link was stripped. Koji)

Link to a wiki page  with the link to the wiring spreadsheet (Yehonathan)

  15108   Wed Jan 1 04:53:11 2020 gautamUpdatePSLMapping the PSL electronics

For the IMC servo board, it'd be easiest to copy the wiring scheme for the BIO bits as is configured for the CM board (i.e. copy the grouping of the BIO bits on the individual Acromag units). This will enable us to use the latch code with minimal modifications (it was a pain to debug this the first time around). I don't see any major constraint in the wiring assignment that'd make this difficult.

Quote:

PSL wiring spreadsheet is ready. (But the link was stripped. Koji)

Link to a wiki page  with the link to the wiring spreadsheet (Yehonathan)

  15110   Wed Jan 1 16:04:37 2020 YehonathanUpdatePSLMapping the PSL electronics

Done.

Quote:

For the IMC servo board, it'd be easiest to copy the wiring scheme for the BIO bits as is configured for the CM board (i.e. copy the grouping of the BIO bits on the individual Acromag units). This will enable us to use the latch code with minimal modifications (it was a pain to debug this the first time around). I don't see any major constraint in the wiring assignment that'd make this difficult.

Quote:

PSL wiring spreadsheet is ready. (But the link was stripped. Koji)

Link to a wiki page  with the link to the wiring spreadsheet (Yehonathan)

 

  3126   Mon Jun 28 11:27:08 2010 MeganUpdateElectronicsMarconi Phase Noise

Using the three Marconis in 40m at 11.1 MHz, the Three Cornered Hat technique was used to find the individual noise of each Marconi with different offset ranges and the direct/indirect frequency source of the rubidium clock.

Rana explained the TCH technique earlier - by measuring the phase noise of each pair of Marconis, the individual phase noise can be calculated by:

S1 = sqrt( (S12^2 + S13^2 - S23^2) / 2)

S2 = sqrt( (S12^2 + S23^2 - S13^2) / 2)

S3 = sqrt( (S13^2 + S23^2 - S12^2) / 2)

I measured the phase noise for offset ranges of 1Hz, 10Hz, 1kHz, and 100kHz (the maximum allowed for a frequency of 11.1Mhz) and calculated the individual phase noise for each source (using 7 averages, which gives all the spikes in the individual noise curves). The noise from each source is very similar, although not quite identical, while the noise is greater at higher frequencies for higher offset ranges, so the lowest possible offset range should be used. It appears the noise below a range of 10Hz is fairly constant, with a smoother curve at 10Hz.

The phase noise for direct vs indirect frequency source was measured with an offset range of 10Hz. While very similar at high and low frequencies for all 3 Marconis, the indirect source was consistently noisier in the middle frequencies, indicating that any Marconis connected to the rubidium clock should use the rubidium clock as a direct frequency reference.

Since I can't adjust settings of the Marconis at the moment, I have yet to finish measurements of the phase noise at 160 MHz and 80 MHz (those used in the PSL lab), but using the data I have for only the first 2 Marconis (so I can't finish the TCH technique), the phase noise appears to be lowest using the 100kHz offset except at the higher frequencies. The 160 MHz signal so far is noisier than the 11.1 MHz signal with offset ranges of 1 kHz and 10 Hz, but less noisy with a 100 kHz offset.

I still haven't measured anything at 80 MHz and have to finish taking more data to be able to use the TCH technique at 160 MHz, then the individual phase noise data will be used to measure the noise of the function generators used in the PSL lab.

Attachment 1: IndividualNoise11100kHzAllRanges.jpg
IndividualNoise11100kHzAllRanges.jpg
Attachment 2: IndividualNoise11100kHzSeparate.jpg
IndividualNoise11100kHzSeparate.jpg
Attachment 3: DirectvsIndirectNoise.jpg
DirectvsIndirectNoise.jpg
Attachment 4: FG12Noise.jpg
FG12Noise.jpg
  2869   Mon May 3 01:16:50 2010 ranaHowToElectronicsMarconi phase noise measurement setup

 To try the 3-corner hat method on the Marconis, I started to set up the measurement into the DAQ system.

I have set the bottom 2 in the PSL rack to 11.1 MHz. I use a ZP-3MH level 13 mixer as the phase detector. The top one is the LO, it has an output of +13 dBm.

The bottom one is the test unit, it has an output of +6 dBm (should be close to the right level - the IP3 point is +9 dBm). The top one has external DC FM modulation enabled with a FM dev range of 10 Hz.

Mixer output goes through a 50 Ohm in-line termination and then a BLP-5 low pass filter (Steve, please order ~7 of the BLP-1.5 or BLP-1.9 low pass filter from Mini-Circuits) and then into

the DC coupled of a SR560. After some gain and filtering that feedback goes back to the FM input of the top-Marconi to close the PLL. I adjusted the gain to be as small as possible and still stay locked and not

saturate the ADC.

The input to the SR560 is Tee'd into another SR560 with AC coupled input, G = 1000, low-noise. Its output is going directly to the ADC channel - C1:IOO-MC_DRUM1.

I calibrated the channel by opening the loop and setting the AC coupled gain to 1. This lets the Marconis beat at several Hz. The peak-peak signal is equivalent to pi radians.

 

As usual, I was befuddled by the FM input. For some reason I always forget that since its a straight FM input, we don't need any filtering to get a plain 1/f loop. The attached plot shows how we get bad gain peaking if you forget this and use a 0.03 Hz pole in the SR560.

The grey trace is the ADC signal with everything hooked up, but the RF input set to zero (via setting Carrier = OFF in the bottom Marconi). It is the measurement noise.

The BLUE trace is very close to the true phase noise beat of the two Marconis with a calibration error of ~5%. I have not corrected for the loop gain: its right now around a 1 Hz UGF and 1/f. Next, I will measure the loop and compensate for it in the DTT calibration.

Then I'll measure the relative phase noise of 3 of the signal generators to get the individual noises.

Bottom line is that the sensitivity of this approach is good and we should do this rather that use spectrum analyzers since its easy to get very long averages and high res spectra. To get 5x better sensitivity, we can just use the Rai-FET box instead of a SR560 for the readout, but just have to contend with its batteries. Also should try using BALUNs on the RF and LO signals to get rid of the ground loops.

Attachment 1: pn.png
pn.png
  2879   Tue May 4 18:40:27 2010 ranaHowToElectronicsMarconi phase noise measurement setup

To check the UGF, I increased the gain of the PLL by 10 and looked at how much the error point got suppressed. The green trace apparently has a UGF of ~50 Hz and so the BLUE nominal one has ~5 Hz.

The second attachment shows the noise now corrected for the loop gain. IF the two signal generators are equally noisy, then you can divide the purple spectrum by sqrt(2) to get the noise of a single source.

The .xml file is saved as /users/rana/dtt/MarconiPhaseNoise_100504.xml

Attachment 1: Untitled.png
Untitled.png
Attachment 2: ifrnoise.png
ifrnoise.png
  2913   Tue May 11 18:58:49 2010 ranaHowToElectronicsMarconi phase noise measurement setup

Just a little while ago, at 2330 UTC on 5/11, I swapped the phase noise setup to use another Marconi - this time its the 3rd one from the top beating with the 4th one from the top (2nd from the bottom).

After a little while, I swapped over to beat the 33 w/ the 199. I now have all the measurements. For the measurement of the last pair, I inserted BALUN 1:1 transformers on the outputs of both signal generators'.

This last pair appears to be the quietest of the 3 and also has less lines. The lines are mainly at high frequency and are harmonics of 120 Hz. Probably from the Sorensen switching supplies in the adjacent rack.

I double checked that the 10 MHz sync cable was NOT plugged in to any of these during this and that the front panel menu was set to use the internal frequency standard. In the closed loop case, the beat frequency between the 33/199 pair changes by less than ~0.01 Hz over minutes (as measured by calibrating the control signal).

 

Attachment 1: Untitled.png
Untitled.png
  2914   Wed May 12 02:21:56 2010 ranaHowToElectronicsMarconi phase noise measurement setup

Finally got the 3-cornered-hat measurement of the IFRs done. The result is attached.

s12, s23, & s31, are the beat signals between the 3 signal generators.

s1, s2, & s3 are the phase noise of the individual generators made by the following matlab calculation:

%% Do the hat
s1 = sqrt((s12.^2  + s31.^2 - s23.^2) / 2);
s2 = sqrt((s12.^2  + s23.^2 - s31.^2) / 2);
s3 = sqrt((s31.^2  + s23.^2 - s12.^2) / 2);

As you can see, there is now an estimate of the individual noises. We can do better by doing some fitting of the residuals.

The real test will be to replace the noise one here with the good Wenzel oscillator and see how well we can estimate its noise. If the 11 MHz crystals don't show up, I can just try this with the 21.5 MHz one for the PSL.

Attachment 1: pn.png
pn.png
  2570   Thu Feb 4 12:29:04 2010 josephbUpdateComputersMartian IP switch over notes

What is the change:

We will be moving the 131.215.113.XXX ip addresses of the martian network over to a 192.168.XXX.YYY scheme.

What will users notice:

Computer names (i.e. linux1, scipe25/c1dcuepics) will not change.  The domain name martian, will not change (i.e. linux1.martian.).  What will change is the underlying IP address associated with the host names.  Linux1 will no longer be 131.215.113.20 but something like 192.168.0.20.  If everything is done properly, that should be it.  There should be no impact or need to change anything in EPICS for example.  However, if there are custom scripts with hard coded IP addresses rather than hostnames, those would need to be updated, if they exist.

What needs to be done:

Each computer and router will need to either be accessed remotely, or directly, and the configuration files controlling the IP address (and/or dns lookup locations) be modified.  Then it needs to be rebooted so the configuration changes take effect. I'll be making an updated list of computers this week (tracked down via their physical ethernet cables), and next week, probably on Thursday, and then we simply go down the list one by one.

LINUX

For a linux machine, this means checking the /etc/hosts file and making sure it doesn't have old information.  It should look like:

127.0.0.1               localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6

Then change the /etc/sysconfig/network-scripts/ifcfg-eth0 file (or ethX file depending on the ethernet card in question).  The IPADDR, NETWORK, and GATEWAY lines will need to be changed.  You can change the hostname (although I don't plan on it) by modifying the /etc/sysconfig/network file.

The /etc/resolv.conf file will need to be updated with the new DNS server location (i.e. 131.215.113.20 to 192.168.0.20 for example).

SOLARIS

Simlarly to linux, the /etc/hosts file will need to be updated and/or simplified.  The /etc/defaultrouter file will need to be updated to the new router ip.  /etc/defaultdomain will need to be updated.  The /etc/resolv.conf will need to be updated with the new dns server.

vxWorks

Looking at the vxWorks machines, the command bootChange can be used to view or edit the IP configuration.

The following is an example from c1iscey.

-> bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : eeE0
processor number     : 0
host name            : linux1
file name            : /cvs/cds/vw/pIII_7751/vxWorks
inet on ethernet (e) : 131.215.113.79:ffffff00
inet on backplane (b):
host inet (h)        : 131.215.113.20
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1iscey
startup script (s)   :
other (o)            :

value = 0 = 0x0

By updating the the host (name of machine where its mounting /cvs/cds from - i.e. linux1), inet on ethernet (the IP of c1iscey) and host inet (linux1's ip address), we should be able to change all the vxWorks machines.

LINUX1

The DNS server running on linux1 will need to be updated with the new IPs and domain information.  The host file on linux1 will also need to be updated for all the new IP addresses as well.

This will need to be handled carefully as the last time I tried getting away without the host file on linux1, it broke NFS mounting from other machines.  However, as long as the host on linux1 is kept in sync with the dns server files everything should work.

  4603   Tue May 3 00:44:02 2011 KojiConfigurationComputersMartian WIreless Bridge

The Martian wireless bridge has the ethernet cable inserted in the wrong connector.

It should be inserted to one of the four port. Not in the "INTERNET" connector.

Once the connector has been changed, the martian net as well as the internet became accessible from the laptops.

  4135   Tue Jan 11 14:05:11 2011 josephbUpdateComputersMartian host table updated daily

I created two simple cron jobs, one running on linux1 and one running on nodus, to produce an updated copy of the martian host table linkable from the wiki every day.

The scripts live in /opt/rtcds/caltech/c1/scripts/AutoUpdate/.  One is called  updateHostTable.cron and run on linux1 everyday at 4 am, and the other is called moveHostTable.cron which is run on nodus everyday at 5am.

The new link has been added to the Martian Host table wiki page  here.

 

  14465   Tue Feb 19 19:03:18 2019 ranaUpdateComputersMartian router -> WPA2

I have swapped our martian router's WiFi security over to WPA2 (AES) from the previous, less-secure, system. Creds are in the secrets-40-red.

  10196   Mon Jul 14 16:51:07 2014 NichinUpdateElectronicsMartian table updated, Named server restarted

 [Nichin, Jenne]

The martian lookup tables are located at /etc/bind/zones/martian.db  and etc/bind/zones/rev.113.168.192.in-addr.arpa

Jenne updated these to include santuzza.martian  192.168.113.109

 

 

The method to restart named server given at  https://wiki-40m.ligo.caltech.edu/Martian_Host_Table  also does not work.

I restarted it using  >sudo /etc/init.d/bind9 restart

The named server is now updated and works fine. :)  I will update the 40m wiki now.

  1339   Thu Feb 26 01:24:44 2009 YoichiUpdateComputersMartian wireless is back
Today, a new wireless router arrived.
I configured and installed it. Now the martian wireless network is back.
I updated the wiki page about the wireless network.
http://lhocds.ligo-wa.caltech.edu:8000/40m/Network
  1325   Thu Feb 19 16:29:43 2009 YoichiUpdateComputersMartian wireless router bad
The Martian wireless router is dead.
I rebooted it several times, but it hangs up in a minute.
I will ask steve to buy a new one.
  9026   Mon Aug 19 09:54:13 2013 SteveUpdatesafetyMasayuki receives safety training

Masayuki Nakano, a student of Seiji's from ICRR / U Tokyo, is visiting us here at the 40m lab for the next couple months.

He received 40m specific basic safety training this morning.

  16135   Wed May 12 14:23:20 2021 JordanUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units
Attachment 1: Moments_of_Inertia_SI.PNG
Moments_of_Inertia_SI.PNG
  16136   Wed May 12 16:53:59 2021 KojiUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units

No, this is the property of the suspension assembly. The mass says 10kg

Could you do the same for the testmass assembly (only the suspended part)? The units are good, but I expect that the values will be small. I want to keep at least three significant digits.

  16137   Wed May 12 17:06:52 2021 JordanUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units

Here are the mass properties for the only the test mass assembly (optic, 3" ring, and wire block). (Updated with g*mm^2)

Quote:

No, this is the property of the suspension assembly. The mass says 10kg

Could you do the same for the testmass assembly (only the suspended part)? The units are good, but I expect that the values will be small. I want to keep at least three significant digits.

 

Attachment 1: Moments_of_Inertia_SI.PNG
Moments_of_Inertia_SI.PNG
  16146   Wed May 19 18:29:41 2021 KojiUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units

Calculation for the SOS POS/PIT/YAW resonant frequencies

- Nominal height gap between the CoM and the wire clamping point is 0.9mm (cf T970135)

- To have the similar res freq for the optic with the 3" metal sleeve is 1.0~1.1mm.
As the previous elog does not specify this number for the current configuration, we need to asses this value and the make the adjustment of the CoM height.

Attachment 1: SOS_resonant_freq.pdf
SOS_resonant_freq.pdf SOS_resonant_freq.pdf
Attachment 2: SOS_resonant_freq.nb.zip
  3740   Tue Oct 19 00:24:07 2010 DmassOmnistructureElectronicsMassive restocking of the 40m

I had a number of delinquent items on the sign out list from the 40m. I returned about half, and ordered replacements for most of the other half.

I put the photodiodes on the SP table, and the 560 on the electronics  bench.

  120   Tue Nov 20 18:35:20 2007 JohnHowToComputersMatLab in Emacs
If you can't get MatLab to run in emacs try adding the following to the .emacs file

(setq matlab-shell-command-switches '("-nojvm"))

This stops the gui opening.

To start MatLab type M-x matlab-shell.
To enter MatLab mode M-x matlab-mode.

I've done this on LINUX3.

To run MatLab in emacs under windows one can use MatLabShell http://www.cs.umb.edu/~ram/matlabShell/index.html
  251   Mon Jan 21 23:30:03 2008 AndreyUpdateComputer Scripts / ProgramsMatlab Program for Q-factor measurements (XARM -> ITMX and ETMX)

Finally I overcame difficulties with adapting Sonia's Matlab programs for XARM (Sonia's program was for MC),

and now there exists a Matlab program that makes a fit of a ringdown curve and calculates Q-factor for a mirror ITMX.

Specifically, this program allows to measure ringdown, fit it and calculate Q-factor for the ITMX-mirror for a specific value of
"C1:SUS-ITMX_SUSPOS_GAIN".

Attached is a plot of a ringdown curve and its fit for the value 4.0 in channel "C1:SUS-ITMX_SUSPOS_GAIN".

Calculations yield the result Q=3.7+-0.2 for the value 4.0 in channel "C1:SUS-ITMX_SUSPOS_GAIN".

As Robert started 10 minutes ago the long procedure of the whole interferometer locking,
I cannot disturb the interferometer now, so I will measure Q-factors for various combinations of suspension damping gain on Tuesday.

I will also easily modify the program for measuring Q-factors of ETMX-mirror and make measurements with ETMX on Tuesday.

The Matlab scripts are in directory /cvs/cds/caltech/users/rodionov/Q-Factors/
Attachment 1: Example-ITMX_POS_40.png
Example-ITMX_POS_40.png
  12859   Wed Mar 1 16:00:41 2017 gautamUpdateComputer Scripts / ProgramsMatlab R2016b installed

Since it would be nice to have the latest version of Matlab, with all its swanky new features (?), available on the control room computers and Optimus, I downloaded Matlab R2016b and activated it with the Caltech Campus license. I installed it into /cvs/cds/caltech/apps/linux64/matlab16b. Specifically, I would like to run the coating optimization code on Optimus, where I can try giving it more stringent convergence criterion to see if it converges to a better spot.

I trust that this way, we don't interfere with any of the rtcds stuff.

If I've done something illegal license-wise or if this is likely to cause havoc, please point me to what is the correct way to do this.

GV 18 Mar 2017: Though I installed this using the campus network license key, this seems to only work on Rossa. If I run it on the other control room machines/Optimus, it throws up a licensing error. I will check with Larry W. as to how to resolve this...

 

  6083   Wed Dec 7 20:55:44 2011 Vladimir, DenUpdatedigital noiseMatlab error

Quote:

It would be useful to see some plots so we could figure out exactly what magnitude and phase error correspond to "gross" and "miserable".

To show why Matlab is bad in filtering at small cut-off frequencies we did the same thing in Matab, Octave and R: we've taken the low-pass chebyshev filter of the type 1, order 6, ripple 1 dB, the sampling frequency was 16384 Hz and cut-off frequency varied from 1 to 1000 Hz. Here is the plot for the gain of the zpk model versus to cut-off frequency.

gain_cmp.png

We can see that Matlab's gain shows surprising gains for low cut-off frequencies through for > 100 Hz it is fine. In the next table we compare gain from Foton, Matlab, R and Octave for the same filter. So Foton is also good

freq R_gain matlab_gain octave_gain Foton_gain
1 3.05186270655452e-24 4.8824152e-22 3.05186271e-24 3.05186e-24
10 3.04698335947093e-18 1.8268825e-16 3.04698336e-18 3.04698e-18
100 2.99910841393644e-12 2.9991084e-12 2.99910841e-12 2.99911e-12
1000 2.60247212721439e-06 2.6024721e-06 2.60247213e-06 2.60247e-06
ELOG V3.1.3-