40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 150 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  10117   Tue Jul 1 18:06:13 2014 nichinUpdateComputer Scripts / ProgramsNetwork Analyzer NWAG4395A data acquisition

EDIT: The script and template file have been moved to /opt/rtcds/caltech/c1/scripts/general/netgpibdata/

 

___________________________________________________________________________________________________________

The NEW and IMPROVED script for remotely getting data from Agilent 4395A network analyzer is located at /users/nichin

This script is quite different from the one in Elog 10108 and fetches us both magnitude and phase. There is an added feature of setting the IF Bandwidth.

The network analyzer is located at crocetta.martian (192.168.113.108)

How to run the script:

> python NWAG4395A_data_acq.py [filename.yml]

  1. The script accepts sweep parameters and output options via a .yml file that is written following a template that can be found at /users/nichin/NWAG4395A_parameters.yml
  2. The data obtained is stored as a .dat file and the corresponding details regarding the acquired data is in a .par parameter file
  3. Separate .dat and .par files are created for phase and magnitude of voltage data.
  4. You can choose to get a plot of the data obtained by specifying it in the .yml file. The plots are automatically stored as PDF.
  5. Plots, data and parameter files are all stored in a new folder that is created with a timestamp in its name.
  6. NOTE: Plotting options are only available in computers running numpy versions of 1.6.0 or above.(Currently only Ottavia and Chiara)

Test Run:

I connected a simple 2MHz Low pass filter between the modulation output and signal input of the NA and ran a scan from 100KHz to 20MHz. The script was run from Ottavia.

The expected plot was obtained and is attached here.

Current work:

Setting up the RF switch in rack 1Y1 to select between required PDs and scripts to tell it which channel to choose over the Ethernet.

 

Attachment 1: LPF2_01-07-2014_175443.pdf
LPF2_01-07-2014_175443.pdf
  153   Sun Dec 2 17:37:33 2007 ranaOmnistructureComputersNetwork Cabling in the Office
We all know that we've spent many integrated man hours trying to figure out why our network connections
in the office area don't work. Usually its because of the bad hub around the Tobin/Osamu desk.

I pried open some of the wall conduit today and it looks pretty easy to fish cables through. I think
its time we finally did that. It may be a little disruptive, but I propose we get Larry to come over
and figure out what needs to happen for us to get regular 100 Mbit ports on the walls. These can
then all go over and get connected to a switch in the rack that holds linux1.

Opinions / comments ?
  977   Mon Sep 22 16:51:27 2008 YoichiHowToComputersNetwork GPIB
I was able to make the wireless connected GPIB interface work with SR785.
Now you can download data from SR785 through network, wherever it is located.
Say good bye to floppy disks.

I wrote an installation note in the wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/GPIB

I wrote a new script called "netgpibdata.py" which works similarly as "getgpibdata.py".
It is in the 40m svn. Instructions on how to use it is on the above mentioned wiki page.
  983   Tue Sep 23 00:47:24 2008 YoichiHowToComputersNetwork GPIB

Quote:

I wrote a new script called "netgpibdata.py" which works similarly as "getgpibdata.py".
It is in the 40m svn. Instructions on how to use it is on the above mentioned wiki page.


netgpibdata.py is now installed on the controls machines (/cvs/cds/caltech/scripts/general/netgpibdata/netgpibdata.py).
You can use it like,
netgpibdata.py -i 131.215.113.106 -d AG4395A -a 10 -f spectrum01

In this example, data from Agilent 4395A analyzer at GPIB address 10 connected to the GPIB-LAN box with the IP address 131.215.113.106
is downloaded and saved to spectrum01.dat. The measurement parameters are saved to spectrum01.par.
  10984   Fri Feb 6 15:29:29 2015 ericqUpdateCDSNetwork Shenanigans

Just now we had another EPICS freeze. The network was still up; i.e. I could ssh to chiara and fb, who both seemed to be working fine.

I could ping c1lsc successfully, but ssh just hung. fb's dmesg had some daqd segfault messages, so I telnet'ed to daqd and shut it down. Soon after, EPICS came back, but this is not neccesarily because of the daqd restart...

  11867   Wed Dec 9 18:45:58 2015 KojiSummaryGeneralNetwork Topology Check

[Eric Q, Gautam, Koji]

We went through the network connections to produce the mapping of the instruments.
Gautam summarized the notes into a spread sheet. See attachments.

We didn't find any irregular connections except for the connection of NETMGR port of c1ioo to Martian Network.
This cable was removed.

Attachment 1: Network_topology_9Dec2015.xlsx
Attachment 2: Network_topology_9Dec2015.pdf
Network_topology_9Dec2015.pdf Network_topology_9Dec2015.pdf Network_topology_9Dec2015.pdf
  12963   Wed May 3 16:00:00 2017 gautamSummaryGeneralNetwork Topology Check

[johannes, gautam]

I forgot we had done this last year already, but we updated the control room network switch labels and double checked all the connections. Here is the status of the connections and labels as of today:

There are a few minor changes w.r.t. labeling and port numbers compared to the Dec 2015 entry. But it looks like there was no IP clash between Rossa and anything (which was one of the motivations behind embarking on this cleanup). We confirmed by detatching the cable at the PC end of Rossa, and noticed the break in the ping signals. Plugging the cable back in returned the pings. Because Rossa is currently un-bootable, I couldn't check the MAC address.

We also confirmed all of this by using the web browser interface for the switch (IP = 192.168.113.249).

Attachment 1: Network_topology_3May2017.pdf
Network_topology_3May2017.pdf
  5114   Thu Aug 4 00:04:52 2011 JennyUpdatePSLNetwork analyzer and PD set up to measure amplitude response of PZT

Today I placed the PDA255 photodiode on the PSL table to catch the small amount of beam power reflected by the second polarizing beam splitter in my setup. I plugged the PD output to the oscilloscope to measure the voltage output and positioned the PD such that the voltage output was maximized. At best I was able to achieve a 300 mV DC output voltage from the PD, (which seems a bit low, as the PD is specified to go from 0 to 5 V and the specifications say that the response becomes nonlinear after 10 mW/cm^2 and my beam has an intensity of approximately 5 mw/cm^2. I would therefore expect to get more beam power but after over an hour of maneuvering, 300 mV was the highest voltage output I could get).

I am planning, tomorrow afternoon, to take a measurement of the amplitude response of the PZT driving the NPRO laser. I moved the 4395 spectrum/network analyzer to near the PSL table and connected the RF output to an RF splitter. I fed one output of that into the PZT and the other output into the R port on the network analyzer. I fed the PD output into the A port. I plan to measure A/R as a function of driving frequency, sweeping from 10 Hz to 30 mHz.

I also worked to improve the mode matching of the NPRO beam coming from the AP table to the reference cavity. I drove the temperature of the NPRO at 0.100 Hz with an amplitude of 0.300 V, which Koji told me corresponds to a 1GHz change in the laser frequency. The transmission from the cavity is being monitored by a camera connected to a TV monitor, and also by a PD connected to an oscilloscope. I then repositioned the second lens in my mode matching setup in an attempt to increase the transmission peaks from the zeroth order spacial mode and decrease the transmission peaks from higher order modes. I may have improved the mode matching slightly but I was unable to improve it significantly.

  5126   Fri Aug 5 18:29:35 2011 JennyUpdatePSLNetwork analyzer and PD set up to measure amplitude response of PZT

Quote:

Today I placed the PDA255 photodiode on the PSL table to catch the small amount of beam power reflected by the second polarizing beam splitter in my setup. I plugged the PD output to the oscilloscope to measure the voltage output and positioned the PD such that the voltage output was maximized. At best I was able to achieve a 300 mV DC output voltage from the PD, (which seems a bit low, as the PD is specified to go from 0 to 5 V and the specifications say that the response becomes nonlinear after 10 mW/cm^2 and my beam has an intensity of approximately 5 mw/cm^2. I would therefore expect to get more beam power but after over an hour of maneuvering, 300 mV was the highest voltage output I could get).

I am planning, tomorrow afternoon, to take a measurement of the amplitude response of the PZT driving the NPRO laser. I moved the 4395 spectrum/network analyzer to near the PSL table and connected the RF output to an RF splitter. I fed one output of that into the PZT and the other output into the R port on the network analyzer. I fed the PD output into the A port. I plan to measure A/R as a function of driving frequency, sweeping from 10 Hz to 30 mHz.

I also worked to improve the mode matching of the NPRO beam coming from the AP table to the reference cavity. I drove the temperature of the NPRO at 0.100 Hz with an amplitude of 0.300 V, which Koji told me corresponds to a 1GHz change in the laser frequency. The transmission from the cavity is being monitored by a camera connected to a TV monitor, and also by a PD connected to an oscilloscope. I then repositioned the second lens in my mode matching setup in an attempt to increase the transmission peaks from the zeroth order spacial mode and decrease the transmission peaks from higher order modes. I may have improved the mode matching slightly but I was unable to improve it significantly.

The ABSL beam had been blocked so that it wouldn't enter the interferometer. I moved the block so that the beam I've been using is unblocked by the beam going to the interferometer is still blocked.

I positioned a fast lens (f=28.7mm) a little over an inch in front of the PDA255 in order to decrease the spot size incident on the PD. I adjusted the rotation angle of the half wave plate to maximize the transmitted power through the PBS to the cavity and minimize the power reflected to my PD. I then adjusted the lens potion to fix the beam on the PD. The voltage output of the PD is now 150mW, but I have the ability to increase the incident power by rotating the wave plate slightly.

Now all I need is to set up the network analyzer again to record the amplitude response to modulating the PZT from 10 Hz to 30 MHz, reduce the input voltage into the analyzer using a DC block.

  5144   Mon Aug 8 20:23:14 2011 JennyUpdatePSLNetwork analyzer and PD set up to measure amplitude response of PZT

Quote:

Quote:

Today I placed the PDA255 photodiode on the PSL table to catch the small amount of beam power reflected by the second polarizing beam splitter in my setup. I plugged the PD output to the oscilloscope to measure the voltage output and positioned the PD such that the voltage output was maximized. At best I was able to achieve a 300 mV DC output voltage from the PD, (which seems a bit low, as the PD is specified to go from 0 to 5 V and the specifications say that the response becomes nonlinear after 10 mW/cm^2 and my beam has an intensity of approximately 5 mw/cm^2. I would therefore expect to get more beam power but after over an hour of maneuvering, 300 mV was the highest voltage output I could get).

I am planning, tomorrow afternoon, to take a measurement of the amplitude response of the PZT driving the NPRO laser. I moved the 4395 spectrum/network analyzer to near the PSL table and connected the RF output to an RF splitter. I fed one output of that into the PZT and the other output into the R port on the network analyzer. I fed the PD output into the A port. I plan to measure A/R as a function of driving frequency, sweeping from 10 Hz to 30 mHz.

I also worked to improve the mode matching of the NPRO beam coming from the AP table to the reference cavity. I drove the temperature of the NPRO at 0.100 Hz with an amplitude of 0.300 V, which Koji told me corresponds to a 1GHz change in the laser frequency. The transmission from the cavity is being monitored by a camera connected to a TV monitor, and also by a PD connected to an oscilloscope. I then repositioned the second lens in my mode matching setup in an attempt to increase the transmission peaks from the zeroth order spacial mode and decrease the transmission peaks from higher order modes. I may have improved the mode matching slightly but I was unable to improve it significantly.

The ABSL beam had been blocked so that it wouldn't enter the interferometer. I moved the block so that the beam I've been using is unblocked by the beam going to the interferometer is still blocked.

I positioned a fast lens (f=28.7mm) a little over an inch in front of the PDA255 in order to decrease the spot size incident on the PD. I adjusted the rotation angle of the half wave plate to maximize the transmitted power through the PBS to the cavity and minimize the power reflected to my PD. I then adjusted the lens potion to fix the beam on the PD. The voltage output of the PD is now 150mW, but I have the ability to increase the incident power by rotating the wave plate slightly.

Now all I need is to set up the network analyzer again to record the amplitude response to modulating the PZT from 10 Hz to 30 MHz, reduce the input voltage into the analyzer using a DC block.

 I rolled the network analyzer over to the PSL table (on the south side). I'm borrowing the DC block from Kiwamu's green locking setup. I'm going to first measure the amplitude response of a low pass filter to made sure that the analyzer is outputting what I expect. Then I will measure the laser PZT amplitude response. I plan to finish the measurement and return the network analyzer to it's usual location tonight.

  16656   Thu Feb 10 14:39:31 2022 KojiSummaryComputersNetwork security issue resolved

[Mike P / Koji / Tega / Anchal]

IMSS/LIGO IT notified us that "ILOM ports" of one of our hosts on the "114" network are open. We tried to shut down obvious machines but could not identify the host in question. So we decided to do a bit more systematic search of the host.

[@Network Rack]
- First of all, we disconnected the optical cables coming to the GC router while the ping is running on the AIRLIGO connected laptop (i.e. outside of the 40m network). This made the ping stopped. This means that the issue was definitely in the 40m.
- Secondly, we started to disconnect (and reconnect) the ethernet cables from the GC router one by one. We found that the ping response stops when the cable named "NODUS" was disconnected.

[@40m IFO lab]
- So we tracked the cable down in the 40m lab. After a while, we identified that the cable was really connected to nodus.

- Nodus was supposed to have one network connection to the martian network since the introduction of the bidirectional NAT router (rather than the old configuration with a single direction NAT router).

- In fact, the cable was connected to "non-networking" port of nodus. (Attachment 1). I guess the cable was connected like this long time, but somehow the ILOM (IPMI) port was activated along with the recent power cycling.

- The cable was disconnected at nodus too. (Attachment 2) And a tape was attached to the port so that we don't connect anything to the port anymore.

Attachment 1: PXL_20220210_220816955.jpg
PXL_20220210_220816955.jpg
Attachment 2: PXL_20220210_220827167.jpg
PXL_20220210_220827167.jpg
  449   Fri Apr 25 13:53:11 2008 josephbSummaryComputersNetwork setup
This is the promised more in detail summary from Andrey's log ID 444.

What we did was go around to each hub, one at a time, unplug the network connection, and figure out which light on which hub went out. We then, went back to the control room, confirmed that we were still able to talk to the devices connected to the hub, and if not, rebooted them. This process was repeated for each hub.

As it stands, the hubs located at the ends of arms (in racks 1X4 and 1Y9) are connected to the really old 24 port 10 Base T hub located in 1Y7. In addition, the 5 port SMC hub is plugged into the 8 port SMC switch in 1Y5 (which actually has enough ports to simply move all the connections over to it, so I'm not sure why there are two...).

All other hubs/switches are connected back to the control room 24 port switch.

Attached is a simple diagram of the network connections for the 40m lab.
Attachment 1: 40m_network_90.pdf
40m_network_90.pdf
  464   Mon May 5 11:04:30 2008 robOmnistructureComputersNetwork setup

Mafalda was not connected to the network, and so our DMF-based seisBLRMS has not been running for ~1 week. I traced this to a broken ethernet cable connecting mafalda to the network switch in the rack next to the B&W printer. This cable has a broken connector at the switch side, which means it can't stay connected if there's any tension. It needs to be replaced.
  13037   Sun Jun 4 14:19:33 2017 ranaFrogsComputersNetwork slowdown: Martians are behind a waterwall

A few weeks ago we did some internet speed tests and found a dramatic difference between our general network and our internal Martian network in terms of access speed to the outside world.

As you can see, the speed from nodus is consistent with a Gigabit connection. But the speeds from any machine on the inside is ~100x slower. We need to take a look at our router / NAT setup to see if its an old hardware problem or just something in the software firewall. By comparison, my home internet download speed test is ~48 Mbit/s; ~6x faster than our CDS computers.


controls@megatron|~> speedtest
/usr/local/bin/speedtest:5: UserWarning: Module dap was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path
  from pkg_resources import load_entry_point
Retrieving speedtest.net configuration...
Testing from Caltech (131.215.115.189)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Race Communications (Los Angeles, CA) [29.63 km]: 6.52 ms
Testing download speed................................................................................
Download: 6.35 Mbit/s
Testing upload speed................................................................................................
Upload: 5.10 Mbit/s
controls@megatron|~> exit
logout
Connection to megatron closed.
controls@nodus|~ > speedtest
Retrieving speedtest.net configuration...
Testing from Caltech (131.215.115.52)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Phyber Communications (Los Angeles, CA) [29.63 km]: 2.196 ms
Testing download speed................................................................................
Download: 721.92 Mbit/s
Testing upload speed................................................................................................
Upload: 251.38 Mbit/s

Attachment 1: Screen_Shot_2017-06-04_at_1.47.47_PM.png
Screen_Shot_2017-06-04_at_1.47.47_PM.png
Attachment 2: Screen_Shot_2017-06-04_at_1.44.42_PM.png
Screen_Shot_2017-06-04_at_1.44.42_PM.png
  1067   Wed Oct 22 12:37:47 2008 josephbUpdateComputersNetwork spreadsheet
Attached in open office format as well as excel format is spreadsheet containing all the devices with IP addresses at the 40m. Please contact me with any corrections.
Attachment 1: 40m_network_10-15-08.ods
Attachment 2: 40m_network_10-15-08.xls
  7993   Mon Feb 4 15:26:10 2013 JamieUpdateComputer Scripts / ProgramsNew "getdata" program to pull NDS channel data, including test points

I've added a new program called getdata (to scripts/general/getdata) that will conveniently pull arbitrary data from an NDS server, either DQ or online (ie. testpoints).

Start times and durations may be specified.  If past data is requested, you must of course be requesting DQ channels.  If no start time is specified, data will be pulled "online", in which case you can specify testpoints.

If an output directory is specified, the retrieved data will be stored in that directory in files named after the channels.  If an output directory is not specified, no output will be

Help usage:

 

controls@pianosa:~ 0$ /opt/rtcds/caltech/c1/scripts/general/getdata --help
usage: getdata [-h] [-s START] [-d DURATION] [-o OUTDIR] channel [channel ...]

Pull online or DQ data from an NDS server. Use NDSSERVER environment variable
to specify host:port.

positional arguments:
  channel               Acquisition channel. Multiple channels may be
                        specified acquired at once.

optional arguments:
  -h, --help            show this help message and exit
  -s START, --start START
                        GPS start time. If omitted, online data will be
                        fetched. When specified must also specify duration.
  -d DURATION, --duration DURATION
                        Length of data to acquire.
  -o OUTDIR, --outdir OUTDIR
                        Output directory. Data from each channel stored as
                        '.txt'. Any existing data files will be
                        automatically overwritten.
controls@pianosa:~ 0$ 

  2892   Thu May 6 19:51:22 2010 JenneUpdatePEMNew 'Seismic Spectrum of the 40m'

For reasons unknown, the seismic spectra posted above Rosalba has been wrong since ~January when it was first posted.  The noise that we were claiming was waaaay lower than is really possible.

Rana and I checked the calibrations, and the numbers in DTT for the Ranger and the Guralp are correct (it's unknown what was being used at the time of the bad plot) - Cal for the Guralp is 3.8e-9 m/s, and for the Ranger is 1.77e-9 m/s.

Something is funny with the accelerometer calibration.  Hopefully Kevin's investigation will sort it out.  Their calibration used to be 1.2e-7 m/s^2 , but it was changed to be 7e-7 m/s^2 to match the noise level of the accelerometers with the seismometers at ~10Hz. We need to go through the calibration carefully and figure out why this is!

Posted above Rosalba for easy reference, and attached below, is the new seismic spectra.  The black trace is when the Ranger's mass is locked down, and the teal circle markers indicate the Guralp Spec-Sheet Noise Floor.

** Rana says> the y-axis in Jenne's plot is (m/s)/sqrt(Hz). The Guralp has a velocity readout bandwidth of 0.03-40 Hz, so we would have to modify the calibration to make it right in those frequencies. I believe the Ranger cal has the correct poles in it. The huge rise at low frequencies is because of the 1/f noise of the SR560.

Attachment 1: SeisRef_6May2010_AccelCalFudged.png
SeisRef_6May2010_AccelCalFudged.png
  4526   Thu Apr 14 19:05:17 2011 KojiUpdateLSCNew (temporary) LSC screen

[Jenne Koji]

The PD signals are transmitted to the suspension now.

The trigger thresholds were set to -1. This means the triggers are always on.

Attachment 1: temporary_LSC_screen.png
temporary_LSC_screen.png
  11788   Thu Nov 19 14:50:34 2015 Max IsiUpdateGeneralNew 2D histogram plot for summary pages

A new type of plot is now available for use in the summary pages, based on EricQ's 2D histogram plots (elog 11210). I have added an example of this to the SandBox tab (https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20151119/sandbox/). The usage is straighforwad: the name to be used in config files is histogram2d; the first channel corresponds to the x-axis and the second one to the y-axis; the options accepted are the same as numpy.histogram2d and pyploy.pcolormesh (besides plot limits, titles, etc.). The default colormap is inferno_r and the shading is flat.

Attachment 1: C1-ALL_AB3834_HISTOGRAM2D-1131926417-86400.png
C1-ALL_AB3834_HISTOGRAM2D-1131926417-86400.png
  382   Fri Mar 14 16:56:03 2008 DmassBureaucracyComputersNew 40m control machine.
I priced out a new control machine from Dell and had Steve buy it.

GigE cards (jumbo packet capable) will be coming seperately.

Specs:
Quad core (2+GHz)
4 Gigs @ 800MHz RAM
24" LCD
low end video card (Nvidia 8300 - analog + digital output for dual head config)

No floppy drive on this one (yet?)
  1215   Sun Jan 4 13:17:23 2009 AlanOmnistructureComputer Scripts / ProgramsNew 40mWebStatus
I have set up some code in /cvs/cds/caltech/scripts/webStatus along with a cronjob on controls@nodus to generate a webStatus every half hour, at 40mWebStatus

you are welcome to add/delete lines corresponding to interesting EPICS channels, in the template /cvs/cds/caltech/scripts/webStatus/webStatus_template.html . The 2nd number is the "golden" value of the EPICS channel; it can be edited by hand, or one could copy a "golden" webStatus.html to webStatus_template.html . I think it's probably premature to automate this...

I noticed that Yoichi also has a cron job posting 40m medm screen snapshots. Very nice.

controls@nodus also runs a third cronjob, which checks if the nightly backup fails, and if so, sends an email to me.

I guess we need some kind of "official" crontab file for controls@nodus so that we know how/where to add things. So, I put one in /cvs/cds/caltech/crontab/controls@nodus.crontab
  1216   Mon Jan 5 11:21:05 2009 AlanOmnistructureComputer Scripts / ProgramsNew 40mWebStatus

Quote:

I guess we need some kind of "official" crontab file for controls@nodus so that we know how/where to add things. So, I put one in /cvs/cds/caltech/crontab/controls@nodus.crontab


Alan and I agreed that we should edit the crontab by "crontab -e" command rather than editing the "official" crontab in /cvs/cds/caltech/crontab/.
After confirming that the new crontab works as expected, you are encouraged to make a copy of the new crontab into /cvs/cds/caltech/crontab/ as a backup.
Then do "svn ci" in the directory.
  13707   Mon Mar 26 23:49:27 2018 gautamUpdateGeneralNew ADC Adaptor Board installed in C1LSC expansion chassis

Todd informed me that the ADC Timing adaptor boards we had ordered arrived today. I had to solder on the components and connectors as per the schematic, though the main labor was in soldering the high density connectors. I then proceeded to shut down all models on c1lsc (and then the FE itself). Then classic problem of all vertex machines crashing when unloading models on c1lsc happened (actually Koji noticed that this was happening even on c1ioo). Anyways this was nothing new so I decided to push ahead. 

I had to get a cable from Downs that connects the actual GS ADC card to this adaptor board. I powered off the expansion chassis, installed the adaptor board, connected it to the ADC card and restarted the expansion chassis and also the FE. I also reconnected the SCSI cable from the AA board to the adaptor card. It was a bit of a struggle to get all the models back up and running again, but everything eventually came back(after a few rounds of hard rebooting). I then edited the c1x04 and c1lsc simulink models to reflect the new path for the X arm ALS error signals. Seems to work alright.

At some point in the afternoon, I noticed a burning smell concentrated near the PSL table. Koji traced the smell down to the c1lsc expansion chassis. We immediately powered the chassis off. But Steve later informed me that he had already noticed an odd burning smell in the morning, before I had done any work at the LSC rack. Looking at the newly installed adaptor card, there wasn't any visual evidence of burning. So I decided to push ahead and try and reboot all models. Everything came back up normally eventually, see Attachment #1. Particle count in the lab seems a little higher than usual (actually, according to my midnight measurement, they are ~factor of 10 lower than Steve's 8am measurements), but Steve didn't seem to think we should read too much into this. Let's monitor the situation over the coming days, Steve should comment on the large variance seen in the particle counter output which seems to span 2 orders of magnitude depending on the time of the day the measurement is made... Also note that there is a BIO card in the C1LSC expansion chassis that is powered by a lab power supply unit. It draws 0 current, even though the label on it says otherwise. I a not sure if the observed current draw is in line with expectations.


The spare (unstuffed) adaptor cards we ordered, along with the necessary hardware to stuff them, are in the Digital FE hardware cabinet along the east arm.

Steve:  particle count in the 40m is following outside count, wind direction, weather condition .....etc. The lab particle count is NOT logged ! This is bad practice.

Attachment 1: CDS_20180326.png
CDS_20180326.png
  9197   Thu Oct 3 10:29:03 2013 masayukiUpdateGreen LockingNew ALS autolocker flowchart

 

 [Manasa, Masayuki]

We made a new flowchart of ALS autolocker. We added the additional step to find the beat note frequency. We have to find a way to read the PSL temperature. By reading the PSL temperature we can decide the sweep range for the end green laser temperature with the curve which measured in previous measurement (in this entry)

We have three thresholds of error signal. One is the threshold for checking the arms are stabilized or not. It should be some hundreds count. Another threshold is to check that the suspensions are not kicked. This should be some thousands counts (in flow chart, it is 2K counts). The other is to check the optimal servo gain. If the servo gain is too high, the UGF is also too high and we will not have enough gain margin. The error signal start to oscillate at the UGF. We will check this oscillation and find the optimal gain. In flow chart this threshold is 1K counts.

Attachment 1: flowchart.pdf
flowchart.pdf
  9865   Mon Apr 28 10:59:54 2014 KojiUpdateLSCNew ALS servo design: expected error signals

The expected error signals derived from the estimated free running error signals of the ALS.

1) Previously estimated free-running noise (blue)
2) Previous in-loop ALS error signal (red)
3) Estimated error signal with the new servo (green)
4) Out-of-loop noise of the ALS with the arm controlled with the IR PDH (black)

Now the error signal (green) is expected to be very white.
The suppressed noise between 3 to 20Hz are below the sensing noise level.
There seems a little excess at 24.5Hz and 28Hz. If it is limiting the RMS, we need to take care of them.

Attachment 1: ALSX_SPE_new.pdf
ALSX_SPE_new.pdf
Attachment 2: ALSY_SPE_new.pdf
ALSY_SPE_new.pdf
  9867   Mon Apr 28 11:08:11 2014 KojiUpdateLSCNew ALS servo design: expected error signals

Here are the MATLAB scripts and LISO codes for all of these servo analyses

Attachment 1: 140421_ALS_servo.zip
  9866   Mon Apr 28 11:03:57 2014 KojiConfigurationLSCNew ALS servo implemented for the X arm

The new ALS/LSC servo was implemented for the X arm.

I'll upload more data later but here I make quick remarks:

- We need to give the gain of 12 to have correct UGF with the ALS.

- With this servo, the Xarm PDH lock oscillates with the gain of 0.02. We need to lower the gain to 0.015.
  Also FM trigger should be changed not to trigger unused FMs (FM7/8)

  9874   Tue Apr 29 01:10:16 2014 KojiConfigurationLSCNew ALS servo implemented for the X arm

New ALS servo performance

Attachment 1:

Comparison between the old (orange) and new (red). The new error signal (red) is suppressed like a white noise as expected.

Comparison between the out-of-loop evaluation (black) and the in-loop signal (red). Below 50Hz the out-of-loop is limited by the sensor-noise like something.
This out-of-loop stability was measured with the ALS stayed at the top of the resonance and calibrated the POX11 error signal.

Attachment 2:

New ALS servo with the LSC PDH signal. When the PDH signal is used for the control, FM4 is additionally used.
In this condition, the error signal was measured and calibrated into frequncy noise (Hz/sqrtHz).

By comparing the POX (with the new servo) and POY (with the old servo) signals, one can see that the new servo has better supression below 30Hz with almost no cost at ~100Hz.

Attachment 1: ALSX_SPE.pdf
ALSX_SPE.pdf
Attachment 2: ALSX_PDH_SPE.pdf
ALSX_PDH_SPE.pdf
  10554   Tue Sep 30 17:26:18 2014 ericqUpdateLSCNew AO cable in place

I've installed a new 2pin lemo cable going from the CM servo out to in2 of the MC servo board, and removed the temporary BNC. I used some electrical tape to give the cable some thickness where the lemo head screws on to try to strain relieve the solder joints; hopefully this cable is more robust than the last. 

I put an excitation into the CM board, and saw it come out of MC_F, so I think we're set. 

  5489   Tue Sep 20 20:58:35 2011 AnamariaConfigurationLSCNew AP Table Drawing

As promised, I have made a final AP table drawing, including the MC camera relocation changes by Kiwamu. I have posted it in the wiki on the tables list, and on the AP table page I've attached the inkscape .svg I used to make it, if someone needs to do small modifications.

Attached is a pdf version of it.

Big changes:

1) REFL beam has been split into 4, to go in equal powers and equal beam size to the now 4 REFL RFPDs, 11, 33, 55 and 165. A lens had to be added for REFL165 because it's a 1mm PD instead of 2mm like the other 3.

2) MC camera has moved.

3) I've cleaned up most of the random components on the table, put them away, and tidied up the cabling.

 

Attachment 1: APtableSep20th.pdf
APtableSep20th.pdf
  7082   Fri Aug 3 03:24:13 2012 JenneUpdateASSNew ASS screens

I wanted to try out the ASS tonight, but I wanted some kinds of screens thrown together so I would know what I was doing.  Turns out screens take longer than I thought.  Am I surprised? Not really. 

They're probably at the ~85% mark now, but I should be able to try out the ASS tomorrow I think.

  12077   Fri Apr 15 03:02:44 2016 ericqUpdateGeneralNew AUX laser measurements

The free running PSL+AUX beat frequency noise spectrum has been measured via PLL. AUX laser PZT PM and AM responses were measured too. 


Rough notes about these measurements:

Laser -> QWP -> HWP -> PBS -> 10% BS -> Beat
3.4Vpp out of PD, (40% contrast)
20dB Coupler, output to analyzer, coupled output to Mixer (-a few dBm, didn't check specifically)
Mixer: ZP-3+, BLP-5.1 at output
LO: OCXO @ 36MHz 13dBm->5dB Att-> +8dBm LO at Mixer

Got ~65mVpp out of Mixer

Mixer out -> SR560, LP 3Hz, G=500 -> Pomona Summing node -> Laser PZT
~30kHz UGF ~30 deg phase

Spectra, OLG via SR785 taken with free running PSL, anthropomorphic temperature servo. Data sheet calibration used for PZT. SR560 output noise dominates over analyzer, mixer, PD. Spectrum looks ok, I think.

PM measured with AG4395. High impedance probe used for laser PZT, otherwise couldn't lock. PM calibrated via mixer voltage span for fringe-to-fringe. 

PSL beam blocked, AUX power increased to read 8.0V, AM measured with AG4395.

AM/PM doesn't look to dissimilar to old measurements on wiki. ~230kHz looks like a fine modulation freq. 

Still to be done to AUX laser:
- joint PSL/AUX temperature sweeps
- Output power vs. diode current
- Beam profile

Attachment 1: aux_innolight_freqPSD.pdf
aux_innolight_freqPSD.pdf
Attachment 2: aux_innolight_AMPM.pdf
aux_innolight_AMPM.pdf
Attachment 3: aux_innolight_data.zip
  12078   Fri Apr 15 18:35:57 2016 gautamUpdateGeneralNew AUX laser measurements

I've performed the temperature sweep of PSL vs Innolight 1W AUX laser.

  • I followed the procedure in this elog - started by turning of FSS and FSS Slow servos, closed the PSL shutter, noted down the value of PSL temperature
  • As noted in elog 3759, there are multiple temperatures at which a beat can be found. I recorded all that I could find. The IR beat frequency was < 20MHz at the temperatures recorded (and had an amplitude of a few dBm, but I used a 20dB coupler to look at the signal on the HP spectrum analyzer
  • The PMC unlocked each time I changed the PSL temperature, but the PMC autolocker worked for me every time
  • We should use curve 3 in attachment 1, it is the most reliable set of temperatures at which a beat can be found
  • PSL diode current was 2.100A, AUX laser diode current was 2.001A
  • Attachment 2 is the data

It remains to measure the output power vs diode current, and the beam profile. I will do the latter on the SP table where there is a little more space. Because we have 1W from this NPRO, the knife-edge method requires a power meter that has a large dynamic range and is sensitive enough to profile the beam accurately. After consulting the datasheets of the power meters we have available (Scientech, Ophir and Coherent) together with Koji, I have concluded that the Coherent calorimeter will be suitable. Its datasheet claims it can accurately measure incident powers of up to 100uW, although I think the threshold is more like 5-10mW, but this should still be plenty to get sufficient resolution for a Gaussian intensity profile with peak intensity of 1W. We also checked that the maximum likely power density we are likely to have during the waist measurement process (1W in a beam of diameter 160um) is within the 6kW/cm^2 quoted on the datasheet.

Attachment 1: PSL_AUX_TEMP_SCAN.pdf
PSL_AUX_TEMP_SCAN.pdf
Attachment 2: PSL_AUX_TEMP_SCAN.mat
  12968   Wed May 3 17:16:30 2017 PrafulUpdateElectronicsNew Altium Schematic Design for Microphone Amp

I made an Altium schematic for the microphone amplifier circuit for fabrication.

mic_schematicv2.pdf

Attachment 1: mic_schematicv2.pdf
mic_schematicv2.pdf
  6301   Tue Feb 21 18:39:11 2012 kiwamuUpdateGreen LockingNew BBPDs installed

Two new BBPDs have been installed on the PSL table.

The first one was installed by Koji a few days ago, and I stalled the second one today.

They will serve as beat-note detectors for the green locking.

Next step : I have to lay down a long SMA cable which goes from the BBPD to the IOO rack.

  6966   Thu Jul 12 11:55:00 2012 JenneUpdateGreen LockingNew BS mounts for PSL beats - Y is finished

Yuta and I bought some new BS mounts so that we could use the 4th port of the beamsplitters which are combining the PSL green and the arm transmitted beam, just before the Beat PD for each arm.  I just placed the Yarm one, and have aligned the light onto both the Beat PD and the Trans DC PD. 

I'll do the Xarm after lunch.

  9361   Fri Nov 8 17:19:27 2013 JenneUpdateLSCNew Broadband PD for POP 22/110

Here is a photo of the board inside the broadband photodiode (one of them) that I took from the Gyro experiment:

IMG_1255.JPG

This PD is Serial Number S1200271.

We need to have a look at the schematic, figure out what's in here now, and then modify this to be useful (appropriate resonances / notches, as well as amplification) for POP 22/110.

  9363   Sat Nov 9 10:25:43 2013 KojiUpdateLSCNew Broadband PD for POP 22/110

General Remarks on the BBPD

- To form the LC network: Use fixed SMD inductors from Coilcraft. SMD tunable capacitors are found in the shelf right next to Steve's desk.
  If the tuning is too coarse, combine an appropriate fixed ceramic SMC C and the tunable C (in parallel, of course)

- L1/C1a/C1b pads are specifically designed for an additional notch

- Another notch at the diode stage can be formed between the middle PD pin (just left of the marking "C3b") to the large GND pad (between C1a/C1b to C3a).
  You have to scratch off the green resin with a small flat screw driver (or anything similar)

- A notch at the amplifier stage can be formed between the output of MAR-6SM ("+" marking)  and one of the GND pads (left side of the "U1" marking)

- The original design of the PD is broadband. So additional notches on the diode stage provides notches and resonances.
  Check if the resonances do not hit the signal frequencies.

- One would think the PD can have resonant feature to reduce the coupling of the undesired signals.
  In some sense it is possible but it will be different from the usual resonant tank circuit in the following two points.

  * Just adding a parallel L between the cathode and ground does not work. As this DC current should be directed to the DC path,
    L&C combo should be added. In fact this actually give a notch-resonance pair. This C should be big enough so that you can ignore it
    at the target resonant frequency. Supply complimentary small C if necessary to keep low impedance of the Cs at the target frequency.
    (i.e. Check SRF - self-resonant frequency of the big C)

  * Since the input impedance of MAR-6SM is 50Ohm, the top of the resonant curve will be cut at 50Ohm. So the resultant shape looks
    like a bandpass rather than a resonance.

- So in total, simulation of the circuit is very important to shape the transimpedance. And, consider the circuit can not be formed as simulated
  because of many practical imperfections like stray Ls and Cs.

 

  9481   Tue Dec 17 14:06:59 2013 ranaUpdateLSCNew Broadband PD for POP 22/110

 I looked at the BBPD design so that we could make a POP22/110. It looks like it will be easy (I hope).

 The first attachment shows the schematic with the RF notch modified to handle 55 MHz. As long as the capacitor in this notch can be kept to below 20 pF, it doesn't degrade the noise so much,

The second attachment shows the TF and input referred noise. We ought to be able to get 20 pA/rHz at the input to the first RF amplifier.

The LISO files are in the svn under liso/examples/aLIGO_BBPD/,

Later, if we have to notch more than just 55 MHz, we can add a notch between the 2 RF amplifiers as Koji has done for the REFL165.

Attachment 1: POP22110sch.pdf
POP22110sch.pdf
Attachment 2: POP22110.pdf
POP22110.pdf POP22110.pdf
  4522   Thu Apr 14 00:21:28 2011 KojiUpdateCDSNew C1LSC code running

[Jamie, Jenne, Koji]

We installed the new c1lsc and started the process.

We still need to configure bunch of the EPICS variables, matrices, and some of the filters.
This should be done in order to transmit the signals to the suspensions.
Jenne is going to work on this task tomorrow (Friday) morning,
and Koji will take over the task afternoon/evening.

  2940   Mon May 17 17:17:49 2010 josephb, steve, alberto, kiwamuUpdateCDSNew CDS computers now in racks.

We placed 3 new computers in the racks.  One in 1X4 (machine running SCX) and 2 in 1Y4 (LSC and SUS).  These are 1U chassis, 4 core machines for the CDS upgrade.  I will be bringing over 2 IO chassis and their rails over tomorrow, one to be placed in 1Y4, and 1 in 1X4.

We still need some more 40 pin adapter cables and will send someone over this week to make them.  However, once we have those, we should be able to get two to three machines going, one end computer/chassis and the SUS computer/chassis.

After tomorrow we are still going to be owed 1 computer, another dolphin fiber, a couple of blue boxes, and the LSC, IO, and Y end IO chassis.  We also realized we need further fiber for the timing system.  We're going to need to get and then run fiber to both ends, as well as to 1X3, where the LSC IO chassis will be.

 

  4583   Thu Apr 28 16:12:19 2011 josephb, jamieUpdateCDSNew CDS model SVN

New SVN

We are now using the LIGO CDS SVN for storing our control models.

The SVN is at:

https://redoubt.ligo-wa.caltech.edu/websvn/

The models are under cds_user_apps, then trunk, then approriate subsystem (ISC for c1lsc for example), c1 (for caltech 40m), then models.

We have checked out /cds_user_apps to /opt/rtcds/.

So to find the c1lsc.mdl model, you would go to /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1lsc.mdl

This SVN is shared by many people LIGO, so please follow good SVN practice.  Remember to update models ("svn update") before doing commits.  Also, after making changes please do an update to the SVN so we have a record of the changes.

New Practices

We are creating soft links in the /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/simLink/ to the models that you need to build.  So if you want to add a new model, please add it to the cds_users_apps SVN in the correct place and create a soft link to the simLink directory.

lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1sus.mdl -> /opt/rtcds/cds_user_apps/trunk/SUS/c1/models/c1sus.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1sup.mdl -> /opt/rtcds/cds_user_apps/trunk/SUS/c1/models/c1sup.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1spy.mdl -> /opt/rtcds/cds_user_apps/trunk/SUS/c1/models/c1spy.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1spx.mdl -> /opt/rtcds/cds_user_apps/trunk/SUS/c1/models/c1spx.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1scy.mdl -> /opt/rtcds/cds_user_apps/trunk/SUS/c1/models/c1scy.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1scx.mdl -> /opt/rtcds/cds_user_apps/trunk/SUS/c1/models/c1scx.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1mcs.mdl -> /opt/rtcds/cds_user_apps/trunk/SUS/c1/models/c1mcs.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1x05.mdl -> /opt/rtcds/cds_user_apps/trunk/CDS/c1/models/c1x05.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1x04.mdl -> /opt/rtcds/cds_user_apps/trunk/CDS/c1/models/c1x04.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1x03.mdl -> /opt/rtcds/cds_user_apps/trunk/CDS/c1/models/c1x03.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1x02.mdl -> /opt/rtcds/cds_user_apps/trunk/CDS/c1/models/c1x02.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1x01.mdl -> /opt/rtcds/cds_user_apps/trunk/CDS/c1/models/c1x01.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1rfm.mdl -> /opt/rtcds/cds_user_apps/trunk/CDS/c1/models/c1rfm.mdl
lrwxrwxrwx 1 controls controls      55 Apr 28 14:41 c1dafi.mdl -> /opt/rtcds/cds_user_apps/trunk/CDS/c1/models/c1dafi.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1pem.mdl -> /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1pem.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1mcp.mdl -> /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1mcp.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1lsp.mdl -> /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1lsp.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1lsc.mdl -> /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1lsc.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1ioo.mdl -> /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1ioo.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1gpv.mdl -> /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1gpv.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1gfd.mdl -> /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1gfd.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1gcv.mdl -> /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1gcv.mdl
lrwxrwxrwx 1 controls controls      54 Apr 28 14:41 c1ass.mdl -> /opt/rtcds/cds_user_apps/trunk/ISC/c1/models/c1ass.mdl

  2861   Thu Apr 29 15:48:47 2010 josephbUpdateCDSNew CDS overview diagram in wiki

I've added a diagram in the wiki under IFO Upgrade 2009-2010->New CDS->Diagram section Joe_CDS_Plan.pdf (the .svg file I used to create it is also there).  This was mostly an exercise in me learning inkscape as well as putting out a diagram with which lists control and model names and where they're running.

A direct link is: CDS_Plan.pdf

  5154   Tue Aug 9 13:34:40 2011 NicoleSummarySUSNew Calibration Plots for Photosensors

Here are the new calibration plots for my photosensors. These calibrations were done using a translation stage.

The linear region for the first photosensor appears to be between 15.2mm and 30 mm

ps1.jpg

The linear region for the second photosensor appears to be between 12.7mm and 22.9mm

ps2.jpg

The slope for both is -0.32 V/mm  (more precisely, -0.3201 V/mm for PS 1 and -0.3195 V/mm for PS 2)

 

  2860   Thu Apr 29 14:37:16 2010 josephbUpdateCDSNew Channel Name to Memory Location file

Awhile back we had requested a feature for the RCG code where a single file would define a memory location's name as well as its explicit hex address.  Alex told me it had been implemented in the latest code in SVN.  After being unable to find said file, I went back and talked to him and Rolf.  Rolf said it existed, but had not been checked into the SVN yet. 

I now have a copy of that file, called G1.ipc.  It is supposed to live in /cvs/cds/caltech/chans/ipc/ , so I created the ipc directory there.  The G1.ipc file is actually for a geo install, so we'll eventually make a C1.ipc file.

The first couple lines look like:

# /cvs/cds/geo/chans/ipc/G1.ipc
[default]
ipcType=SHMEM
ipcRate=2048
ipcNum=0
desc=default entry

[G1:OMC-QPD1P]
ipcType=SHMEM
ipcRate=32768
ipcNum=0
desc=Replaces 0x2000
#[G1:OMC-NOTUSED]
#ipcType=SHMEM
#ipcRate=32768
#ipcNum=1

[G1:OMC-QPD2P]
ipcType=SHMEM
ipcRate=32768
ipcNum=1
desc=Replaces 0x2008

 

There are also section using ipcType IPC:

[G1:SUS-ADC_CH_24]
ipcType=PCI
ipcRate=16384
ipcNum=1
desc=Replaces 0x20F0
[G1:SUS-ADC_CH_25]
ipcType=PCI
ipcRate=16384
ipcNum=2
desc=Replaces 0x20F0

 

Effectively the ipcNum tells it which memory location to use, starting with 0x2000 (at least thats how I'm interpreting it.  Every entry of a given ipcType has a different ipcNum which seems to be correlated to its description (at least early on - later in the file many desc= lines repeat, which I think means people were copy/pasting and got tired of editing the file.  Once I get a C1.ipc file going, it should make our .mdl files much more understandable, at least for communicating between models.  It also looks like it somehow interacts with the ADCs/DACs with ipcType PCI, although I'm hoping to get a full intro how to use the file tomorrow from Rolf and Alex.

  271   Sat Jan 26 02:02:43 2008 JohnSummaryGeneralNew Channels
I added the following channels.

# C1ASC_QPDs
[C1:SUS-ETMY_QPDSUM_MON]
[C1:SUS-ETMY_QPDYAW_MON]
[C1:SUS-ETMY_QPDPIT_MON]

[C1:SUS-ETMX_QPDSUM_MON]
[C1:SUS-ETMX_QPDYAW_MON]
[C1:SUS-ETMX_QPDPIT_MON]

The old .ini file is /cvs/cds/caltech/chans/daq/C0EDCU_26_1_2008.ini
  14311   Tue Nov 20 17:38:13 2018 ranaUpdateUpgradeNew Coffee Machine

Rana, Aaron, Gautam

The old Zojirushi has died. We have received and comissioned our new Technivoorm Mocha Master today. It is good.

  17019   Tue Jul 19 17:18:34 2022 JCUpdateElectronicsNew Coil Driver on Rack 1X3

[Yehonathan, JC]

Yehonathan and I began to put the electronics on Rack 1X3. To do this, we had to move the monitor over the the PD testing table. Before mounting the Coil Drivers, we added numbers to the spaces to follow the rack plan Koji has provided. The drivers which have been mounted are PRM (Slots 10,11), BS (Slots 15, 16), ITMX (Slots 26, 27), and ITMY (34, 35).

Attachment 1: 22DC1767-6073-4D82-BEED-915318B57C03.jpeg
22DC1767-6073-4D82-BEED-915318B57C03.jpeg
  14141   Mon Aug 6 20:41:10 2018 aaronUpdateDAQNew DAC for the OMC

Gautam and I tested out the DAC that he installed in the latter half of last week. We confirmed that at least one of the channels is can successfully drive a sine wave (ch10, 1-indexed). We had to measure the output directly on the SCSI connector (breakout in the FE hard drive cabinet along the Y arm), since the SCSI breakout box (D080303) seems not to be working (wiring diagram in Gautam's elog from his SURF years).

I added some DAC channels to our c1omc model:
PZT1_PIT
PZT1_YAW
PZT2_PIT
PZT2_YAQ
 
And determined that when we go to use the ADC, we will initially want the following channels (even these are probably unnecessary for the very first scans):
TRANS_PD1
TRANS_PD2
REFL_PD
DVMDC (drive voltage monitor, DC level)
DVMAC ("", AC level, only needed if we dither the length)
 
I attach a screenshot of the model, and a picture of where the whitening/dewhitening boards should go in the rack.
Attachment 1: OMCDACmdl.png
OMCDACmdl.png
  14159   Mon Aug 13 20:21:10 2018 aaronUpdateOMCNew DAC for the OMC

[aaron, gautam]

We finished up making the new c1omc model  (screenshot attached).

The new channels are only four DAC for ASC into the OMC, and one DAC for the OMC length:

C1:OMC-ASC_PZT1_PIT
C1:OMC-ASC_PZT1_YAW
C1:OMC-ASC_PZT2_PIT
C1:OMC-ASC_PZT2_YAW
C1:OMC-PZT
 
The model compiles and we can change the channel values, so we are all set to do this OMC scan on the software side.
Attachment 1: c1omcSCREENSHOT.png
c1omcSCREENSHOT.png
ELOG V3.1.3-