40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 257 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  13568   Tue Jan 23 01:33:23 2018 gautamUpdateElectronicsWhitening filter D990694

After discussing with Koji, we looked at the aLIGO incarnation of this board. Interestingly, it too has a similar topology of 4 switchable gain stages with gains of 24, 12, 6 and 3dB. The main differences are that they use single Op27 ICs instead of the quad LT1125s, and also, they use a different combination of feedback resistors to realize the various gains. 

We considered upping the feedback resistance (R15, R143) on the 24dB gain stage of our boards from (1k, 66.5ohms) to (3k, 200ohms) as on the aLIGO boards - but this doesn't really help? Because KCL demands that the same current flow in R15 and R143, and so the output Vsat of the op amp and its max current driving capabilities in combination determine if the inverting input can follow the non inverting input?

As Hartmut points out in his note, he was able to access the full range of ADC voltages when the gain was set to 3dB, despite the fact that the LT1125 was still getting internally saturated. Operating with minimum 24dB whitening gain doesn't really solve the problem either because the problem just gets shifted to the next gain stage in the chain, and we still have saturation. I also don't have a feeling for how much differential voltage these LT1125s can sustain before they are damaged - I guess the planned THD check will reveal if they are okay or not.

It seems to me like the only way to truly fix this problem of one stage saturating and screwing up the others is to use single Op27s (or equivalent) in place of the quad LT1125s. The aLIGO design also has a series resistance to the non-inverting input - this can help prevent current overdraw from the previous stage (due to a lowered input impedance of the OpAmp - but I wonder how low this can go?).


this is the note from Hartmut Grote on this topic from 2004


  13572   Wed Jan 24 00:48:47 2018 gautamUpdateElectronicsWhitening filter D990694

I plan to do some characterization of this problem. The plan is to use THD as a metric for whether we are having hidden saturations. Pg 9 of the LT1125 datasheet tells us what fraction of THD to expect. I will use one of the several unused DAC channels available at the LSC rack to drive a 100Hz sine wave into one of the inputs of the whitening chassis, and measure the THD up to a reasonable harmonic number (will probably be set by the ADC noise) for (i) various whitening gain settings and (ii) various input signal amplitudes.

The motivation is to attempt to quantify the problem better:

  1. How bad is it to have one or more of the OpAmps in the quad IC either saturated to its voltage rails, or max output current?
  2. Can we reproduce Hartmut's observations?
  3. Are the OpAmps already irreversibly damaged because of extended abuse?

Then we can decide what, if anything, to do about this issue.

  3790   Tue Oct 26 22:57:37 2010 JenneConfigurationComputersWhy doesn't DTT work?!?

DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu.  Basically, we can't measure any fast channels with DTT.  I keep getting the error: "Unable to select testpoints."  Sadface.

Similar things are true for DataViewer.  The same limited number of fast channels, and no data found:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Is this a framebuilder problem?  Is this something that the CDS team has on the to-do list?

  3793   Wed Oct 27 10:53:03 2010 josephbConfigurationComputersWhy doesn't DTT work?!?

Test points for the SUS channels should be there.  They have been working previously this week.  Possibly break down points include awgtpman, mx_streams, and the fb itself.  I'll look into that.

As far as other fast channels, there are no other fast front ends running than the suspensions ones we have.  Until additional channels get connected to the front ends and the models updated, those are the channels we have available.  However I am working on getting c1ioo up and running, and we can try connecting in some PEM channels today to the c1sus front end's 4th ADC.



I tried starting a fresh instance of the frame builder, but when I brought the old copy down, it left a pair of zombie or dead mx_stream processes running on c1sus . Basically c1mcs and c1rms were still running, while c1x02 and c1sus came down.  I tried to kill the processes but this caused the c1sus machine to crash.  In the past I've killed left over mx_stream processes running after the frame builder has gone down, but I've never seen them crash the computer.  I'm unsure why this happened since we haven't done any updates of the code, just updated models and daq configuration files.


DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu.  Basically, we can't measure any fast channels with DTT.  I keep getting the error: "Unable to select testpoints."  Sadface.

Similar things are true for DataViewer.  The same limited number of fast channels, and no data found:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Is this a framebuilder problem?  Is this something that the CDS team has on the to-do list?


  4027   Wed Dec 8 14:46:19 2010 josephb, kiwamuUpdateCDSWhy the ETMX daq channels were not recorded last night

When adding the ETMX DAQ channels using the daqconfig gui (located in /opt/rtcds/caltech/c1/scripts/) on C1SCX.ini, we forgot to set the acquire flag to 1 from 0.

So the frame builder was receiving the data, but not recording it.

We have since then added ETMX and the C1SCX.ini file to Yuta's useful "activateDAQ.py" script in /opt/rtcds/caltech/c1/chans/daq/, so that it now sets the sensor and SUSPOS like channels to be acquired at 2k when run.  You still need to restart the frame builder (telnet fb 8087 and then shutdown) for these changes to take effect.

The script now also properly handles files which already have had channels activated, but not acquired.

  14829   Mon Aug 5 17:23:26 2019 gautamSummaryComputersWiFi Settings on asia

The VEA laptop asia was configured to be able to connect to too many WiFi networks - it was getting conflicted in its default position at the vertex and trying to hop between networks, for some reason trying to connect to networks that had poor signal strength. I deleted all options from the known networks except 40MARS. Now the network connection seems much more stable and reliable.

  13905   Thu May 31 19:51:06 2018 KojiUpdateGeneralWiFi router firmware update / rebooting

The model of our martian wifi router (NETGEAR R6400) was found in the FBI router list to be rebooted asociated with the malware "VPNFilter" issue.

I checked the attached devices and found bunch of (legit) devices blocked to access the wifi router. This is not an immediate problem as most of the packets do not go through the wifi router. But potentially a problem in some cases like Wifi enables GPIB adapters. So I marked them to be "allowed".

In this opprtunity, I have updated the firmware of the wifi router and this naturally involved rebooting of the device.


  2664   Tue Mar 9 09:32:31 2010 KojiSummaryGeneralWideband measurement of Fast PZT response

I have measured a wideband response of the fast PZT in the LWE NPRO 700mW in the Alberto's setup.
This is a basic measurement to determine how much phase modulation we can obtain by actuating the fast PZT,
primarily for the green locking experiment.


  • Above 200kHz, there are many resonances that screws up the phase.
  • Modulation of 0.1rad can be easily obtained even at 10MHz if the modulation frequency is scanned.
  • Change of the laser frequency in DC was observed depending on the modulation frequency.
    i.e. At the resonance the laser frequency escaped from the RF spectrum analyzer.
    This may induced by the heat dissipation in the PZT causing the temperature change of the crystal.
  • Some concerns: Is there any undesired AM by the PZT modulation?



1. Locked the PLL of for the PSL-NPRO beating at 20MHz.

2. Added the modulation signal to the NPRO PZT input.
I used the output of the network analyzer sweeping from 100kHz to 1MHz.

3. Measured the transfer function from the modulation input to the PLL error signal.
The PLL error is sensitive to the phase fluctuation of the laser. Found that the first resonance is at 200kHz.
The TF is not valid below 3kHz where the PLL suppresses the modulation.

4. Single frequency modulation: Disconnected the PLL setup.
Plug Marconi into the fast PZT input and modulate it at various frequencies.
Observing with the RF spectrum analyzer, I could see strong modulation below 1MHz.
It turned out later that the TF measurement missed the narrow peaks of the resonances due to the poor freq resolution.

Also the modulation depth varies frequency by frequency because of the resonances.
Scanned the frequency to have local maximum of the modulation depth. Adjusted the
modulation amplitude such that the carrier is suppressed
(J0(m)=0 i.e. m~2.4). As I could not obtain
the carrier suppression at above 1MHz, the height of the carrier and the sidebands were measured.

The modulation frequency was swept from 100kHz to 10MHz.

5. Calibration. The TF measured has been calibrated using the modulation depth obtained at 100Hz,
where the resonance does not affect the response yet.

The responce of the PZT was ~10MHz/V below 30kHz. Looks not so strange although this valure is
little bit high from the spec (2MHz/V), and still higher than my previous experience at TAMA (5MHz/V).
Note that this calibration does not effect to the modulation depth of the single freq measurement as they are independent.

Attachment 1: PZT_response.png
  1105   Sun Nov 2 20:44:58 2008 ranaUpdateASSWiener Filter performance over 5 hours
I took one 2 hour stretch of data to calculate a MISO Wiener filter to subtract the Ranger seismometer
and the 6 Wilcoxon accelerometers from the IOO-MC_L channel. I then used that static filter to calculate
the residual of the subtraction in 10 minute increments for 5 hours. The filter was calculated based upon
the first 2 hours of the stretch.

The MC lock stretch is from Oct 31 03:00 UTC (I think that we are -8 hours from UTC, but the DST confounds me).
So its from this past Thursday night.

I wrote a script (/users/rana/mat/wiener/mcl_comp.m) which takes the static filter and does a bunch of loops
of subtraction to get a residual power spectrum for each 10 minute interval.

In the attached PNG, you can see the result. The legend is in units of minutes from the initial t0 = 03:00 UTC.

BLACK-DASHED -- MCL spectrum before subtraction

I have also used dashed lines for some of the other traces where there is an excess above the unsubtracted data.
Other than those few times, the rest are all basically the same; this indicates that we can do fine with a very
slow adaptation time for the feed-forward filters
-- a few hours of a time constant is not so bad.

After making the plot I noticed that the Ranger signal was totally railed and junky during this time.
This probably explains the terrible performance below 1 Hz (where are those Guralps?)

The second attached image is the same but in spectrogram form.
Attachment 1: f.png
Attachment 2: f1.png
  1111   Mon Nov 3 22:35:40 2008 ranaUpdateASSWiener Filter performance over 5 hours
To speed up the Wiener filter work I defined a 256 Hz version of the original 16kHz IOO-MC_L signal. The
attached plots show that the FE decimation code works correctly in handling the anti-aliasing and
downsampling as expected.
Attachment 1: DAQ.pdf
  1112   Tue Nov 4 00:47:53 2008 ranaUpdateASSWiener Filter performance over 5 hours
Same as before, but now with a working Ranger seismometer.

In the spectrogram, the color axis is now in dB. This is a whitened spectrogram, so 0 dB corresponds to
the average (median) subtraction. The color scale is adjusted so that the large transients are saturated
since they're not interesting; from the DV trend its some kind of huge glitch in the middle of the
night that saturated the MC1 accelerometers only (maybe a pump?).

The attached trend shows the 5 hours used in the analysis.
Attachment 1: f2.png
Attachment 2: f.png
  5102   Wed Aug 3 02:28:08 2011 Manuel, IshwitaUpdateWienerFilteringWiener Filtering in X-arm

Wiener Filtering was applied on the data collected from the X-arm during the time: GPS time-996380715 (Aug 02, 2011. 21:25:00. PDT) to GPS time-996382215 (Aug 02, 2011. 21:50:00. PDT) for a duration of 1500 seconds. During this time the X-arm was locked, we checked it by acquiring data from channel C1:LSC-TRX_OUT_DQ .

The seismometers were near the beam splitter (guralp2) and near MC2 (guralp1).

Target data was obtained from channel C1:LSC-XARM_IN1_DQ.



Following graphs were obtained after applying the Wiener filter:


      1.Seismic data acquired from Guralp1 (X and Y) and Guralp2 (X and Y)                              2.Seismic data acquired from Guralp2 X                                                              3.Seismic data acquired from Guralp2 Y 


These graphs were obtained with srate = 2048 (sample rate) and N = 20000 (order of the filter).

Graph 1 is the best because the black (residual) line is below the red (target) line for low frequencies since we used seismic data from 4 channels. Graph 3 is the worst because we used seismic data from only one Y channel (Y axis of Guralp2) that is less related with the X-arm mirrors' motion since they are oriented orthogonally.

  854   Tue Aug 19 17:00:19 2008 SharonUpdate Wiener TF calibration - update
This is an update for post 814

I added the calibration gains I got for the accelerometers (I realize I am just calibrating the accelerometers to themselves and this is not m/m exactly since we don't really know which accelerometer is doing exactly what we want it to do. However, since we are talking on relative small numbers, this shouldn't really change much).

I also added another missing gain for the seismometer. Rana has previously installed a 4300 ohm resistor in the seismometer, which changed the gain to 4300/(4300+5000) = 0.46 (this is from the manual). Moreover, there is a gain of 100 on the SR560. This comes up to an extra gain of 46, meaning multiplying the seismometer's counts by 1/46.
Attachment 1: m_per_m.png
  6005   Fri Nov 25 12:46:13 2011 MirkoUpdateWienerFilteringWiener filtering tryout

Tried the wiener filter with the TF from p.5900

Tried it out with the TFs from p.5900:


Adding a filter element that compensates the acutator TF makes the MC lose lock.

  1337   Wed Feb 25 11:48:02 2009 JenneUpdatePEMWiener filtering update - work on filtering some S5 DARM_CTRL data

Quick update on my wiener filtering status:

Joe has been helping me get on the GRID, so I now have  a grid certificate, and accounts on most/all of the clusters.

Joe also helped me get menkar to get S5 data so that I can do wiener filtering to the back-data. 


I've been running the wiener filtering algorithm, and right now, it doesn't do anything to improve the DARM_CTRL data.  I am confident that this is because something is funky in the wiener filtering algorithm somewhere.  The indicator of this is that the wiener filtering calculation takes the same amount of time (~95 seconds) to calculate a filter for 64 seconds of data as for 1 hour of data (both for N = 2000 taps). 


For reference, attached are my plots for the wiener filtering result for (1) 64 seconds of S5 data, and for (2) 3600 seconds of S5 data.

These plots were made using H1:DARM_CTRL as the signal to minimize, with 4 seismometers as the witness channels (EX_SEISX, EY_SEISY, LVEA_SEISX, LVEA_SEISY)


I'm working on figuring out what's going on with the filtering algorithm, and why it does work for C1:MC_L minimization, but does not work for H1:DARM_CTRL minimization.




Attachment 1: h1_DARM_64s_4seis_25Feb09.png
Attachment 2: h1_DARM_3600s_4seis_25Feb09.png
  11366   Fri Jun 19 16:54:20 2015 JenneUpdateComputer Scripts / ProgramsWiener scripts in scripts directory

I have put the Wiener filter scripts into  /opt/rtcds/caltech/c1/scripts/Wiener/  .  They are under version control. 

The idea is that you should copy ParameterFile_Example.m into your own directory, and modify parameters at the top of the file, and then when you run that script, it will output fitted filters ready to go into Foton.  (Obviously you must check before actually implementing them that you're happy with the efficacy and fits of the filters). 

Things to be edited in the ParameterFile include:

  • Channel names for the witness sensors (which should each have a corresponding .txt file with the raw data)
  • Channel name for the target
  • Folder where this raw data is saved
  • Folder to save results
  • 1 or 0 to determine if need to load and downsample the raw data, or if can use pre-downsampled data
    • This should probably be changed to just look to see if the pre-downsampled data already exists, and if not, do the downsampling
  • 1 or 0 to determine if should use actuator pre-weighting
  • Data folder for measured actuator TFs (only if using actuator pre-weighting)
    • Actuator TFs can be many different exported text files from DTT, and they will be stitched together to make one set of measurements, where all points have coherence above some quantity (that you set in the ParameterFile)
  • Coherence threshold for actuator data (only use data points with coherence above this amount)
  • Fit order for actuator transfer function's vectfit
  • 1 or 0 to decide if should use preweighting filter
  • zeros and poles for preweighting filters
  • 1 or 0 to decide if should use lowpass after Wiener filters (will be provided corresponding SOS coefficients for this filter, if you say yes)
  • Lowpass filter parameters: cuttoff freq, order and ripple for the Cheby filter
  • New sample rate for the data
  • Number of Wiener filter taps
  • Decide if use brute force matrix inversion or Levinson method
  • Calibrations for witnesses and target
  • Fit order for each of the Wiener filters

I think that's everything that is required.

  4968   Thu Jul 14 17:34:35 2011 Ishwita, ManuelHowToWienerFilteringWiener-Hopf equations

Since we are using Wiener filtering in our project, we studied the derivation of Wiener-Hopf equations. Whatever we understood we have written it as a pdf document which is attached below...

Attachment 1: derivwf.pdf
derivwf.pdf derivwf.pdf derivwf.pdf derivwf.pdf derivwf.pdf derivwf.pdf
  16346   Mon Sep 20 15:23:08 2021 YehonathanUpdateComputersWifi internet fixed

Over the weekend and today, the wifi was acting bad with frequent disconnections and no internet access. I tried to log into the web interface of the ASUS wifi but with no success.

I pushed the reset button for several seconds to restore factory settings. After that, I was able to log in. I did the automatic setup and defined the wifi passwords to be what they used to be.

Internet access was restored. I also unplugged and plugged back all the wifi extenders in the lab and moved the extender from the vertex inner wall to the outer wall of the lab close to the 1X3.

Now, there seems to be wifi reception both in X and Y arms (according to my android phone).


  16350   Mon Sep 20 21:56:07 2021 KojiUpdateComputersWifi internet fixed

Ug, factory resets... Caltech IMSS announced that there was an intermittent network service due to maintenance between Sept 19 and 20. And there seemed some aftermath of it. Check out "Caltech IMSS"


  2849   Tue Apr 27 11:16:13 2010 josephbConfigurationCDSWiki page with CDS .mdl names, shared memory allocation

I've added a new page in the wiki which describes the current naming scheme for the .mdl model files used for the real time code generator.  Note, that these model names do not necessarily have to be the names of the channels contained within.  Its still possible to make all suspension related channels start with C1:SUS- for example.  I'm also allocating 1024 8 byte channels for shared memory address space for each controller and each simulated plant.

The wiki page is here

Name suggestions, other front end models that are needed long term (HEPI is listed for example, even though we don't have it here, since in the long run we'd like to port the simulated plant work to the sites) are all welcome.

  11345   Wed Jun 3 17:04:08 2015 ericqUpdatePEMWilcoxon Accelerometer Huddle Test

I've set up the Wilcoxon accelerometers on the SP table for a huddle test, to estimate their noise levels. 

They're clamped down to the table along the same axis, and their housings are in good contact, in hopes to make them as correlated as possible. 

Steve helped me move the DAQ cables from under the BS/PRM oplev table, to dropping from the cable tray above the POX table, so I could get them plugged in at the SP table. This also helps reduce the rats nest by the access connector, and is a fine location for when the accelerometers are attached at MC1 & MC2. 

A quick glance at DTT shows coherence of >0.9 from about 2-100Hz for all six. A three-corner-hat deal will provide an easy estimate of the noise floor of each one. If we feel like being fancy / accounting for possible gain differences, we could try some MISO wiener action, but that is probably overkill. 

Attachment 1: AccHuddle.jpg
  11350   Wed Jun 10 02:50:39 2015 ericqUpdatePEMWilcoxon Accelerometer Huddle Test

Here are some results for the 3-corner hat subtraction for the six accelerometers, from ~1 hour of data that didn't look to have any sharp features/glitches from human activity in the lab. 

I used the python uncertainties package to try and get an estimate of the uncertainty in the subtracted noise floor, by taking into account every possible possible combination of 3 sensors and the fluctuations in the spectrograms of the subtracted signals. I've attached the python code if anyone is interested in the implementation. 

I pulled out the accelerometer data sheets to read their slightly varying V/g calibration (which differs on the order of a few percent from unit to unit). This improved the subtraction factor from ~20 to over 100 at some frequencies. I've edited the filter modules such that the OUT_DQ channels are already calibrated into m/s^2.

Attachment 1: hats2Acc.png
Attachment 2: 3hatcode.zip
  11367   Sun Jun 21 13:21:03 2015 ranaUpdatePEMWilcoxon Accelerometer Huddle Test

To improve our sensor noise estimate, the ACC cables should be clamped using a rubber pad and a big dog clamp on the SP tabletop before exiting the table. Also the sensors themselves should be covered with a foam box or a double cardboard box. The high-frequency acoustic noise may limit the 10 Hz performance since piezos are not very linear.


I've set up the Wilcoxen accelerometers on the SP table for a huddle test, to estimate their noise levels. 

They're clamped down to the table along the same axis, and their housings are in good contact, in hopes to make them as correlated as possible. 

Wilcoxon. Not Wilconox or Wilco or Wilcoxen. Have some pity on future keyword searchers.

  11391   Sun Jul 5 18:14:13 2015 IgnacioUpdatePEMWilcoxon Accelerometer Huddle Test

Updated: On Thursday/Friday (sorry for late elog) I was messing with Eric's Wilcoxon 731A accelerometer huddle test data that was taken without the box and cables being adjusted properly. Anyways, I performed the three cornered hat analysis as he had done but I also performed a six cornered hat method as well instead of permuting around in pairs of three accelerometers. The following plots of the ASD's show the results,

It is interesting to note the improvement at low frequencies when six accelerometers are used instead of six while at higher frequencies we can clearly see how the results are worst than the three hat results.

I decided to take a mean of all six accelerometers measured ground signal as well as that for their computed selfnoises, this is plotted below,


Notice the obvious improvement along the entire frequency band of the measurements when all accelerometers are used in the data analysis.

I also performed some Wiener filtering of this data. There was an obvious improvement in the results,

The mean of the signals is also plotted below, just as I did with the cornered hat methods,


I also compared the mean self noise of the accelerometers against the manufacturers calculated selfnoise that Rana put up on Github. Both methods are compared against what the manufacturer claims,

As expected the measured noise curves of the Wilcoxon is not as good as what the manufactures stated. This should improve once we redo the huddle test with a better experimental setup. We have some pretty interesting results with the six cornered hat method at around 5 Hz, it is surprisingly accurate given how rough the calculations seemed to be.

I have attached my code for reference: code_accel.zipselfnoise_allsix.png

SEE attachments for better plots of the six accelerometers...

Attachment 5: code_accel.zip
Attachment 6: selfnoise_allsix_miso.png
Attachment 8: selfnoise_allsix.png
  9013   Thu Aug 15 09:34:12 2013 SteveUpdateGeneralWilcoxon cables rescued

Eric and Steve,

 We removed Wilcoxon Accelerometer PS and Amplifier unit under the BS optical tabel yesterday. The six cabels going to DAQ  were labeled and left in place. Gain setting were 100, except channel 3 was 10.

The ~ 40 m long 2 sets of 3 cables were very happy to get their kinks out. Especially the set going just south of ITMX optical  table.

We have to take better care of these cables! Your data will be useless this way.

Attachment 1: rescuedGraycables.jpg
Attachment 2: wilconoxOut.jpg
Attachment 3: chanGains.jpg
  2560   Tue Feb 2 15:30:03 2010 AlbertoFrogsTreasureWild Oats
FYI. Sitting on the top shelf of George I found an opened jar of raspberry jam and an opened jar of creamy peanut butter. Both are branded Wild Oats Market.
"Wild Oats Markets was an operator of natural foods stores and farmers markets in North America... Whole Foods officially completed their buyout of Wild Oats on August 27, 2007 [...]"
  2373   Wed Dec 9 18:01:06 2009 KojiUpdateCOCWiping finished

[Kiwamu, Jenne, Alberto, Steve, Bob, Koji]

We finished wiping of four test masses without any trouble. ITMY looked little bit dusty, but not as much as ITMX did.
We confirmed the surface of the ITMX again as we worked at vertex a lot today. It still looked clean.

We closed the light doors. The suspensions are left free tonight in order to check their behavior.
Tomorrow morning from 9AM, we will replace the door to the heavy ones.

  1101   Thu Oct 30 11:07:25 2008 YoichiUpdateComputersWireless bridges arrived
Five wireless bridges for the GPIB-Ethernet converters arrived.
One of them had a broken AC adapter. We have to send it back.
I configured the rest of the bridges for the 40MARS wireless network.
One of them was installed to the SR785.
I put the remaining ones in the top drawer of the cabinet, on which the label printers are sitting.
You can use those to connect any network device with a LAN port to the 40MARS network.
  2347   Mon Nov 30 11:45:54 2009 JenneUpdateComputersWireless is back

When Alberto was parting the Red Sea this morning, and turning it green, he noticed that the wireless had gone sketchy.

When I checked it out, the ethernet light was definitely blinking, indicating that it was getting signal.  So this was not the usual case of bad cable/connector which is a known problem for our wireless (one of these days we should probably relay that ethernet cable....but not today).  After power cycling and replugging the ethernet cable, the light for the 2.4GHz wireless was blinking, but the 5GHz wasn't.  Since the wireless still wasn't working, I checked the advanced configuration settings, as described by Yoichi's wiki page:  40m Network Page

The settings had the 5GHz disabled, while Yoichi's screenshots of his settings showed it enabled.  Immediately after enabling the 5GHz, I was able to use the laptop at Alberto's length measurement setup to get online.  I don't know how the 5GHz got disabled, unless that happened during the power cycle (which I doubt, since no other settings were lost), but it's all better now.


  1668   Thu Jun 11 14:54:18 2009 josephb, albertoUpdateComputersWireless network

After poking around for a few minutes several facts became clear:

1) At least one GPIB interface has a hard ethernet connection (and does not currently go through the wireless).

2) The wireless on the laptop works fine, since it can connect to the router.

3) The rest of the martian network cannot talk to the router.

This led to me replugging the ethernet cord back into the wireless router, which at some point in the past had been unplugged.  The computers now seem to be happy and can talk to each other.


  6463   Wed Mar 28 21:15:53 2012 ranaOmnistructureComputersWireless router for GC

I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.

The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.

  6465   Thu Mar 29 13:23:05 2012 JenneOmnistructureComputersWireless router for GC


I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.

The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.

 This router was confiscated by the GC guys this morning around ~10am.  They barged in and said that someone at the 40m had connected a new router, and we had magically taken down half of the GC network.  The cable was plugged in to the wrong port on the back of the router. 

Junaid / Christian said that they would "secure" the router, and then reinstall it.  Apparently just having a password didn't satisfy them.  This was the compromise, versus them just taking the router and never bringing it back.


Attachment 1: IMG_0079.JPG
  6467   Thu Mar 29 19:13:56 2012 JamieOmnistructureComputersWireless router for GC

I retrieved the newly "secured" router from Junaid.  It had apparently been hooked up to the GC network via it's LAN port, but it's LAN services had no been shut off.  It was therefore offering a competing DHCP server, which will totally hose a network.  A definite NONO.

The new SSID is "40mWiFi", it's WPA2, and the password is pasted to the bottom of the unit (the unit is back in it's original spot on the office computer rack.

  12649   Wed Nov 30 11:56:56 2016 LydiaUpdateCDSWiring for Acromag auxex replacement

I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:

  • We are getting rid of the slow readbacks from the Anti-Image and Oplev boards, as Rana says they are unnnecessary.
  • The whitening switching for the QPD is currently done by a Contec "fast" binary I/O module, but can be managed by acromag instead. This alllows CAB_1Y9_34 to  be fed directly into the Acromag box since all of its connections can now be managed slow. 
  • There's no need to change the PD whitening scheme around (since the signals never get huge), so we can set those to always be on and then lose those Contec channels. This means all of the necessary pins on CAB_1Y9_10 can go to Acromag. 
  • All the other backplane cables go the the fast machines only. 


Attachment 1: auxex_acromag.pdf
  14287   Fri Nov 9 22:24:22 2018 JonOmnistructure Wiring of Vacuum Acromag Chassis Complete

Wiring of the power, Ethernet, and indicator lights for the vacuum Acromag chassis is complete. Even though this crate will only use +24V DC, I wired the +/-15V connector and indicator lights as well to conform to the LIGO standard. There was no wiring diagram available, so I had to reverse-engineer the wiring from the partially complete c1susaux crate. Attached is a diagram for future use. The crate is ready to begin software developing on Monday. 

Attachment 1: IMG_2987.jpg
Attachment 2: IMG_2985.jpg
Attachment 3: IMG_2986.jpg
  4839   Mon Jun 20 11:04:03 2011 NicoleUpdateSUSWork Plan for Week 2

Here is my work plan for this week:

Current Week Plan (Week 2) (As of 6/17/11)


Setting Up for Horizontal Displacement Measurements

1) Help Steve clean small table for experiment

2) Remove aluminum base from TT suspension

3) Mount shaker onto table base

4) Mount horizontal slider onto table base

5) Connect TT suspension, shaker, and horizontal slider

Begin Assembly of Sensors

1) Begin building circuit for displacement photosensors

2) Calibrate photosensor using linear regions of power versus distance curves

3) Circuit box for photosensors?

  4416   Fri Mar 18 17:55:58 2011 SureshConfigurationGreen LockingWork Plan for Y-end Aux laser installation

A rough time-table and the various tasks are given below:

Note:  700mW NPRO sitting on AP table (Model No: 126-1064-700, Sl No. 415)  = Alberto's laser



Y-arm Aux laser installation

Temperature dependence of frequency of Alberto's laser:

 a) Shifting Alberto's Laser (AL) to the PSL table and setting up a beat frequency measurement between AL and PSL

 b) Determining the frequency vs Temperature curve for the AL

Mar 21st to 25th Bryan and Suresh
2 Re-positioning the Input beam onto the IP-ANG-PD and realigning the X-arm Mar 21st to 25th Kiwamu and his 'team'  :-)

Repositioning the optics on the Y-end  table and relocating Alberto's laser ( at this point it will be rechiristened as Y-End-NPRO )

Mar 27th - 28th
Bryan and Suresh
4 Maximising the doubling effiiciency and obtaining the PD and QPD signals into the CDS Mar 29th - Apr 1st "
5 Aligning the Y-end green to pass through the Y-arm and locking the green to the Y arm Apr 3 - 8th "
6 Aligning the IR beam to the Y- arm and locking the Y arm to the IR Apr 10 - 15 "


  3213   Wed Jul 14 10:00:14 2010 josephbUpdatePhase CameraWork near 1Y2 yesterday

Razib and I were attempting to get the output of a photodiode (PD55A in this case) recorded, so that we could independently measure the slow (~1-10 Hz) fluctuations of the light incident on the camera.  This would then allow us to subtract those fluctuations out, letting us get at the camera noise in the case with signal present (as opposed to just a dark noise measurement when we look at the noise with no signal present).

Originally I was thinking of using one empty patch panel BNCs used for PEM channels down by the 1Y7 rack and go through a 110B, although Alberto pointed out he had recently removed some monitoring equipment, which watched the amplitude modulation at various frequencies of the RF distribution (i.e. 33 MHz, etc).  This equipment output a DC voltage proportional to the amplitude of the RF signals.  The associated channel names were C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_33MHZ_CAL, C1:IOO-RFAMPD_133MHZ, etc.  These are slow channels, so I presume they enter in via the slow computers, probably via pentek (I didn't check that, although in hindsight I probably should have taken the time to find exactly where they enter the system).  The connections them selves were a set of BNCs on the south side, half way up the 1Y2 rack.

We simply chose one, the 33 MHz channel in this case, and connected.  At around this time, the MC did become unlocked, although it looked like it was due to the MC2 watchdog tripping.  The initial theory was we had bumped the Mode Cleaner while looking around for some BNC cables, although from what Rana had to do last night, it probably was the connection.  We were able to restore the watchdog and confirm that the optic started to settle down again.  Unfortunately, I had to leave about 5 minutes later, and didn't do as thorough an investigation as was warranted.

  3215   Wed Jul 14 11:51:48 2010 RazibUpdatePhase CameraWork near 1Y2 yesterday


Razib and I were attempting to get the output of a photodiode (PD55A in this case) recorded, so that we could independently measure the slow (~1-10 Hz) fluctuations of the light incident on the camera.  This would then allow us to subtract those fluctuations out, letting us get at the camera noise in the case with signal present (as opposed to just a dark noise measurement when we look at the noise with no signal present).

Originally I was thinking of using one empty patch panel BNCs used for PEM channels down by the 1Y7 rack and go through a 110B, although Alberto pointed out he had recently removed some monitoring equipment, which watched the amplitude modulation at various frequencies of the RF distribution (i.e. 33 MHz, etc).  This equipment output a DC voltage proportional to the amplitude of the RF signals.  The associated channel names were C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_33MHZ_CAL, C1:IOO-RFAMPD_133MHZ, etc.  These are slow channels, so I presume they enter in via the slow computers, probably via pentek (I didn't check that, although in hindsight I probably should have taken the time to find exactly where they enter the system).  The connections them selves were a set of BNCs on the south side, half way up the 1Y2 rack.

We simply chose one, the 33 MHz channel in this case, and connected.  At around this time, the MC did become unlocked, although it looked like it was due to the MC2 watchdog tripping.  The initial theory was we had bumped the Mode Cleaner while looking around for some BNC cables, although from what Rana had to do last night, it probably was the connection.  We were able to restore the watchdog and confirm that the optic started to settle down again.  Unfortunately, I had to leave about 5 minutes later, and didn't do as thorough an investigation as was warranted.

 Before I left, I disconnected the PD55, so the 33 MHz channel wasn't physically connected to anything!!! Only one end of the wire was connected to the rack while the other was free...

So it wasn't the PD connection that is responsible for MC tripping at the later time...

  14773   Thu Jul 18 19:58:56 2019 gautamUpdateCDSWork on Acromag chassis

Now that the .db files were prepared, I wanted to test for errors. So I did the following:

  1. Acromags were mounted on the DIN rails. Attachment #1 shows the grouping of ADC, DAC and BIO units. They are labelled with their IP addresses.
  2. Wiring of power:
    • Chub had already prepared the backplane with the power connectors, switches and indicator LEDs.
    • So I just had to daisy chain the +24 V (RED) and GND (BLACK) terminals for all the acromags together, which I did using 24 AWG wire (we may want to use heavier gauge given the current draw).
  3. Ethernet cables were used to daisy chain the network connectivity between the various units.  Attachment #1 shows the current state of the chassis box.
  4. Front panel pieces were attached and labelled, see Attachment #2
    • I found it was sufficient to use the front - we may use the rear panel slots when we want to add connections for controlling the c1aux machine channels.
    • The D15 P2 connector panel for the CM board will arrive tomorrow and will be installed then.
  5. Entire setup was connected to power and ethernet, see Attachment #3
    • As usual, the current draw is significant for the collection of Acromags, I got around this problem by using the bench supply to "Parallel" mode to enhance the current driving capacity.
    • For the ethernet connection, I used the office space port #6, which I connected at the network rack end to the eth1 port of the Supermicro.

All the Acromags are seen on the 192.168.114 subnet on c1iscaux3 yes- however, when I run the modbusIOC process, I see various errors in the logfile no, so more debugging is required. Nevertheless, progress.

Update 2245: Turns out the errors were indeed due to a copy/paste error - I had changed the IP addresses for the ADCs from the .115 subnet c1susaux was using, but forgot to do so for the DACs and BIOs. Now, if I turn off the existing c1iscaux so that there aren't any EPICS clashes, the EPICS server initializes correctly. There are still some errors in the log file - these pertain to (i) the mbbo notation, which I have to figure out, and (ii) the fact that this version of EPICS, 7.0.1, does not support channel descriptions longer than 28 characters (we have several that exceed this threshold). I think the latter isn't a serious problem.

Getting closer... Note that I turned off the c1iscaux VME crate to prevent any EPICS server clashes. I will turn it back on tomorrow.

Attachment 1: IMG_7771.JPG
Attachment 2: IMG_7770.JPG
Attachment 3: IMG_7772.JPG
  746   Mon Jul 28 11:20:13 2008 JenneUpdatePSLWork on the FSS and Reference Cavity
[Yoichi, Jenne, Koji]

The Reference Cavity's saga continues....

Thursday, Yoichi and I worked to change the beam that we chose from the 2nd pass through the AOM, to the first order beam rather than the 2nd order beam (see elog #726). After choosing the correct beam, we get 29mW incident on the reference cavity (compared with 4mW before any work began). We adjusted the angle of the AOM in the plane of the table, and got up to 30.6mW. We adjusted the tip/tilt of the AOM and got to 30.7mW (the tip/tilt adjustment made a more significant difference in the work described in elog #726, but after that work, it was probably already pretty close to optimized). We noticed that for the above measurements, we had 2 beams through the Polarizing Beam Splitter and Waveplate (one very dim), so after excluding that beam, the power meter read 30.4mW. We adjusted the curved mirror a little, and got 30.8mW incident on the reference cavity.

We then put a triangle wave into the offset of the MC Servo Board using the "trianglewave <channel> <center> <amplitude> <period> <runtime>" command in a terminal screen. This changes the voltage to the VCO, and thus the frequency response of the AOM. We watch the diffracted spots from the second pass through the AOM, and confirm that the beam we have chosen is not moving, and all the others are. By symmetry, if we chose the first order beam after the first pass through the AOM, and then again chose the first order beam after the second pass, the resulting beam will not move with the frequency change of the AOM.

We saw 1.50V (Refl. PD, unlocked) on the 'scope after aligning the optics to make the newly chosen beam hit the input mirror of the reference cavity. Order of operations for this alignment:
  • Recenter the beam on the 2 lenses that are just after the PBS and the waveplate
  • Adjust pitch and yaw of the two steering mirrors until the beam reflected off the input mirror of the reference cavity is parallel to the incident beam
    • Use a sensor card to check the alignment of the incident and reflected beams, and adjust the steering mirrors to get the alignment close
      • Note the amplitude of the DC output of the Refl. PD with the iris completely open. Close the iris until the signal decreases by ~50%, then adjust the steering mirrors until the original amplitude is regained. Repeat until the iris can be almost completely closed but the Refl. PD signal doesn't change
    • Watch the DC output of the Refl. PD, and maximize the signal on a 'scope
    • Sweep the PZT of the laser using a function generator into the RAMP input on the FSS board (~10Vpp at ~1Hz), OR sweep the temperature of the laser using the trianglewave function on the SLOW FSS channel (amplitude~0.5, period~50)
    • Watch the modes that resonate in the cavity, and adjust pitch and yaw of the steering mirrors to get closer to the TEM00 mode
    • When the TEM00 mode appears in the sweep, stop the sweep, and lock the cavity
    • Watch the DC output of the Transmitted PD, and maximize the signal on a 'scope
  • Celebrate!

After all of this adjusting,
Refl. PD (unlocked) = 1.48V
Refl. PD (locked) = 680mV
Trans. PD (locked) = 6.28V
Power reflected (unlocked) = 26.28mW
Power transmitted (locked) = 13.89mW
Thus, 53% transmission

Next: check the amount of power transmitted by reducing the amplitude of the RF modulator. This reduces the amount of power used by the sidebands, and so should increase the transmission.
Power incident = 27mW
Power transmitted = 17.2mW
Thus, 64% transmission
We then put the RF modulator back where it was originally.

We then replaced the lens mounts for the f=802 and f=687 lenses between the AOM and the reference cavity, to the new mounts that Yoichi bought. Koji helped me realign into the reference cavity, and we got:
Refl. PD (unlocked) = 1.48V
Refl. PD (locked) = 880mV
Trans PD (locked) = 4.64V
Power incident = 26.97mW
Power transmitted = 10.39mW
39% transmission
Since more mode matching etc. is in the works, we left this for the night.

On Friday, we changed the setup of the cameras and PDs for both reflection and transmission, to avoid saturating the PDs and cameras.

On the Refl. side of the reference cavity, we put a W2-PW-1025-UV-1064-45P pickoff between the last mirror and lens before the camera and PD. We moved the camera to the pickoff side of the new optic. We then replaced teh 45UNP beam splitter that split the beam between the PD and the camera with a Y1-1037-45P highly reflective mirror, and put the PD in the old camera location.

On the Trans. side of the ref. cavity, we replaced the BSI-1064-50-1025-45S with a W2 pickoff, and replaced the Y1-1037-45-P highly reflective mirror with the 50/50 beam splitter that was replaced by the W2.

Now we have:
Refl. PD (unlocked) = 1.68V
Refl. PD (locked) = 640mV
Trans PD (locked) = 4.24V
Power incident = 25mW
Power transmitted = 14.48mW
58% transmission

Koji pointed out that when remounting, I had put the f=802 lens ~2cm away from its original position (along the z-axis), so I moved the lens back to where it should be, and realigned into the reference cavity. Since Rana was working on the PMC at the same time, the laser was turned down by about a factor of 100, so my starting measurements were:
Refl. PD (unlocked) = 23.6mV
Refl. PD (locked) = 10.2mV
Trans PD (locked) = 56mV
Power incident = 0.35mW
Power transmitted = 0.16mW
46% transmission

Since it was late on Friday by the time everything was realigned into the ref. cavity (I'm still working on my optics aligning skills), I forgot to measure the transmission after all of my work. I'll do that today (Monday) as soon as Sharon/Koji are done working with the IFO this morning. Also, I'll put up before/after pictures as soon as I find the camera...it seems to have walked off.

Ref. Cav. measurements after Friday's alignment (and after turning the laser power back up to normal):
Refl. PD (unlocked) = 1.58V
Refl. PD (locked) = 304mV
Trans PD (locked) = 3.68V
Power incident = 24.96mW
Power transmitted = 16.45mW
66% transmission

To do: Start the actual mode-matching into the reference cavity.
  10213   Wed Jul 16 01:54:25 2014 NichinUpdateGeneralWork plan for next week

1) Debugging transimpedance calculations in the PDFR

Requires presence of an expert whenever I get inside the lab to take DC measurements or check the illuminating fibers.

2) Creating and incorporating canonical data plots with every measurement of PDFR.

3) Transfer function fitting for transimpedance

4) Improve the Spectrum analyzer scan scripts as mentioned in my elog.

  10283   Mon Jul 28 17:53:00 2014 AkhilUpdateGeneralWork plan for the Upcoming weeks- FOL Project

 [Akhil, Harry]

Work Completed :

 Frequency Counter:

  • Interfacing with the Raspberry Pi
  • Characterization of the FC:          

                                   - Transfer Function 

                                   - Quantization Noise Estimation

Temperature Actuator:

  • Measurement of the Transfer Function

EPICS and Channel Readout:

  •  Creating a new Channel Access Server(SoftIOC)
  •   Piping data from FC into created channels.              

Frequency Offset Locking(FOL) Box Design and Plan:

  • Planning and selection of place for installation.
  • Preparation of the box and routing cables.


Work Plan for Upcoming Weeks:

  • Calibration of the Thermal Actuator TF and PID loop design.
  • Channel Testing after installation of the FOL box inside the 40m.
  • Optics:
    • Measure beam profiles of AUX lasers and PSL.
    • Design coupling telescope, given space constraints at end tables
    • Couple lasers into fibers
    • Connect fibers from lasers to fiber coupled Beam Combiner and Photodiode.
  • Testing of FOL loop after installation of the complete system.



  17158   Fri Sep 23 19:07:03 2022 TegaUpdateComputersWork to improve stability of 40m models running on teststand

[Chris, Tega]

Timing glitch investigation:

  • Moved dolphin transmit node from c1sus to c1lsc bcos we suspect that the glitch might be coming from the c1sus machine (earlier c1pem on c1sus was running faster then realtime).
  • Installed and started c1oaf to remove the shared memory IPC error to/from c1lsc model
  • /opt/DIS/sbin/dis_diag gives two warnings on c1sus2
    • [WARN] IXH Adapter 0 - PCIe slot link speed is only Gen1
    • [WARN] Node 28 not reachable, but is an entry in the dishosts.conf file - c1shimmer is currently off, so this is fine.

DAQ network setup:

  • Added the DAQ ethernet MAC address  and fixed IPV4 address for the front-ends to '/etc/dhcp/dhcpd.conf'
  • Added the fixed DAQ IPV4 address and port for all the front-ends to '/etc/advligorts/subscriptions.txt' for `cps_recv` service
  • Edited '/etc/advligorts/master' by including all the iop and user models '.ini' files in '/opt/rtcds/caltech/c1/chans/daq/' containing channel info and the corresponding tespoint files in '/opt/rtcds/caltech/c1/target/gds/param/'
  • Created systemd environment file for each front-end in '/diskless/root/etc/advligorts/' containing the argument for local data concentrator and daq data transmitter (`local_dc_args` and `cps_xmit_args`). We currently have staggered the delay (-D waitValue) times of the front-ends by setting it to the last number in the daq ip address when we were facing timing glitch issues, but should probably set it back to zero to see if it has any effect.


  • Edited /etc/resolv.conf on fb1 and 'diskless/root' to enable name resolution via for example `host c1shimmer` but the file gets overwritten on chiara for some reason


  1. Frame writing is not working at the moment. It did at some point in the past for a couple of days but stopped working earlier today and we can't quite figure out why. 
  2. We can't get data via diaggui or ndscope either. Again, we recall the working in the past too but not sure why it has stopped working now.   
  3. The cpu load on c1su2 is too high so we should split into two models
  4. We still get the occassional IPC glitch both for shared memory and dolphin, see attachments
Attachment 1: dolphin_state_all_green.png
Attachment 2: dolphin_state_IPC_glitch.png
  15590   Mon Sep 21 12:40:58 2020 gautamUpdateGeneralWorkable IFO recovery

See Attachment #1.

  • The original ETMY actuation matrix was the naive one so I simply retuned everything by adding the butterfly mode appropriately.
  • The cross coupling between the DOFs has not been characterized, but the local damping, Oplev loops, POX/POY locking, simpel Michelson locking, and ASS dither alignemnt all seem to work so I'm thinking this is good enough for now.
  • A copy of the ETMYaux.db file was made, and the slow bias voltage was redistributed among the three available face OSEMs - note that the magnet polarity has to be taken into account.
  • The series resistance on the slow path was reduced from 430 ohms, 1W to 100 ohms, 3W, to allow DC alignment of the cavity axis to the beam axis.
  • Vertex Oplevs were re-centered on their respective QPDs after locking POX/POY and running the ASS dither alignment.
  • The AS spot was a little low on the camera - presumably the SR2/SR3 got macroscopically misaligned. I re-centered the beam on the camera on the AS table (by moving the camera, the beam path was not disturbed).

The beam spot on ETMY looks weird (looks almost like a TEM10 mode), but the one on ITMY seems fine, see Attachment #2. Wonder what's going on there, maybe just a focusing problem?


We need a vent to fix the suspension, but until then what we can do is to redistribute the POS/PIT/YAW actuations to the three coils.

Attachment 1: IFOrecovery.png
Attachment 2: IMG_5345.JPG
  11604   Wed Sep 16 03:37:06 2015 KojiSummaryGreen LockingWorkable delay line setup prepared

[Koji Gautam]

The variable delay line has been setup for practical use. The hardware and basic software are ready.

The delay time is given by [512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns

Giving 511 (LLLL LLLH HHHH HHHH) to C1:LSC-BO_1_0_SET makes the delayline shortest (+0ns).
Giving 0 (LLLL LLLL LLLL LLLL) to C1:LSC-BO_1_0_SET makes the delayline longest (~32ns).

The SR785 was removed from the rack for our access >> Eric

DO setup

- Three CONTEC DO-32L-PE cards are found in the Yarm digital cabinet. (I brought a card from WB, but will bring it back).
- The card was installed in the C1LSC chassis.

- The models for c1x04 and c1lsc were modified to include the card. Once they are restarted, the card was recognized without problem.
  The frame builder also needed to be restarted (Attachment 1&2). The changes were committed to the repository.

- MEDM screen "CDS_BO_STATUS.adl" has been modified to include the bit monitors for the new DO card. (Attachment 3)

Epics values "C1:LSC-BO_1_0_SET" and "C1:LSC-BO_1_1_SET" are hooked up to the DO block.


- The DO board has DB37(F). I made a I/F cable with a DB37(M) crimp connector, DB25 breakout board, and a ribbon cable.
  Pin 1 is connected to pin 14 of the DB25 (GND of the delayline circuit).
  Pin 2~10 are connected to pin 1~9 of the DB25 (Switch 1~9 of the delayline circuit)
  Pin 18 is connected to X01 (external = spare) (Attachment 4)

- [CONFESSION] A bench +15V power supply was prepared to power the transisters of the DO (Attachment 6). The hot side is connected to X01 (not connected to the DB25),
  and the cold side is connected to pin 14 of the DB25. Once we find this is a useful setup we need to make a dedicated interface unit to convert DB37
  into DB25 (and provide more connectivities).

- A DB25 M-F cable was installed on the cable tray above the LSC racks.

Delay line unit

- The delay line box was mounted on 34H of the LSC analog rack (Attachment 5).

- The side cross connect power supply was not available (to be described later). Therefore we decided to use the same +15V supply as the one for the DO card.

- Checked the functionarity of the local switches using a function generator @30MHz and the front panel switches. The maximum (~32ns) delay was confirmed.
  (Just not enough to have 360 deg shift).

- Now the delay line function was tested with the front panel swicth at "ext". We confirmed that the delay time changes with the number given to C1:LSC-BO_1_0_SET.

What we need further

- Implement delay time slider control (511 = 0ns, 0 = 31.94ns). The delay time is given by
  [512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns

- Some independent RF issues I found. (Next entry)

Attachment 1: 21.png
Attachment 2: 51.png
Attachment 3: 46.png
Attachment 4: IMG_20150915_222236066.jpg
Attachment 5: IMG_20150915_234222349.jpg
Attachment 6: IMG_20150915_234323363.jpg
  15513   Mon Aug 10 16:52:04 2020 gautamUpdateBHDWorkable setup prepared

All the details are in E2000436, and documents linked from there, I think an elog would be much too verbose. In summary, a workable setup consisting of

  • 2 DCPDs interfaced with the realtime CDS system. Note that because this circuit is single-ended, while the AA and ADC are differential receiving, there is an overall gain of 0.5. Explicitly, for the 300 ohm DC transimpedance, the conversion is ~350 cts/mW.
  • A local oscillator beam delivered via fiber that is mode-matched (roughly) with the IFO AS beam.
  • A PZT mounted mirror to control the homodyne phase. The PZT (S320) is an obsolete part and it's hard to find a datasheet for it, but if its specs are comparable to the more modern S330, the full stroke is 10 um, for a max applied voltage of 100 V DC, so 100nm/V. c.f. 200V for 3um full stroke of the Noliac.

was prepared.

Last night, I locked the PRMI with the carrier resonant, and convinced myself that the DCPD null stream was sensing the MICH degree of freedom (while it was locked on AS55_Q) with good SNR below ~60 Hz. Above ~60 Hz, in this configuration, the ADC noise was dominating, but by next week, I'll have a whitening board installed that will solve this particular issue. With the optical gain of MICH in this configuration, the ADC noise level was equivalent to ~500 nrad/rtHz of phase noise above ~60 Hz (plots later).

Now, I can think about how to commission this setup interferometrically.

  4144   Wed Jan 12 17:50:21 2011 josephbUpdateCDSWorked on c1lsc, MC2 screens

[josephb, osamu, kiwamu]

We worked over by the 1Y2 rack today, trying to debug why we didn't get any signal to the c1lsc ADC.

We turned off the power to the rack several times while examining cards, including the whitening filter board, AA board, and the REFL 33 demod board.  I will note, I incorrectly turned off power in the 1Y1 rack briefly. 

We noticed a small wire on the whitening filter board on the channel 5 path.  Rana suggested this was to part of a fix for the channels 4 and 5 having too much cross talk.  A trace was cut and this jumper added to fix that particular problem.

We confirmed would could pass signals through each individual channel on the AA and whitening filter boards.  When we put them back in, we did noticed a large offset when the inputs were not terminated.  After terminating all inputs, values at the ADC were reasonable, measuring on from 0 to about -20 counts.  We applied a 1 Hz, 0.1 Vpp signal and confirmed we saw the digital controls respond back with the correct sine wave.

We examined the REFL 33 demod board and confirmed it would work for demodulating 11 MHZ, although without tuning, the I and Q phases will not be exactly 90 degrees apart.

The REFL 33  I and Q outputs have been connected to the whitening board's 1 and 2 inputs, respectively.  Once Kiwamu  adds approriate LO and PD signals to the REFL 33 demod board he should be able to see the resulting I and Q signals digitally on the PD1 I and Q channels.


In an unrelated fix, we examined the suspensions screens, specifically the Dewhitening lights.  Turns out the lights were still looking at SW2 bit 7 instead of SW2 bit 5.  The actual front end models were using the correct bit (21 which corresponds to the 9th filter bank), so this was purely a display issue.  Tomorrow I'll take a look at the binary outputs and see why the analog filters aren't actually changing.




  12244   Tue Jul 5 18:44:39 2016 PrafulUpdateComputer Scripts / ProgramsWorking 40m Summary Pages

After hardware errors prevented me from using optimus, I switched my generation of summary pages back to the clusters. A day's worth of data is still too much to process using one computer, but I have successfully made summary pages for a timescales of a couple of hours on this site: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/


Currently, I'm working on learning the current plot-generation code so that it can eventually be modified to include an interactive component (e.g., hovering over a point on a timeseries would display the GPS time). Also, the 40m summary pages have been down for the past 3 weeks but should be up and working soon as the clusters are now alive.

  3319   Thu Jul 29 12:31:24 2010 josephbUpdateCDSWorking DAC, working IOP - next up SUS

Ok, after a few minutes of talking to Alex, I got the correct "GUI syntax" through my head, and we now have a simple working green end control which in fact puts signals out through the DAC.

Note to self, do not put any additional filters or controls in the IOP module.  Basically just change the master block with GDS numbers, DCU_ID numbers, etc.  When using a control model, copy the approriate ADC and ADC selector or DAC to the control model.  It will magically be connected to the IOP.

A correct example of a simple control model is attached.

Next in line is to get the adapter boxes for SUS into the new 1X5 rack and get started on SUS filter conversion and figuring out which ADC/DAC channels correspond to which inputs.


Attachment 1: Simple_Green_Control.png
ELOG V3.1.3-