40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 54 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  4738   Wed May 18 15:54:50 2011 KojiUpdateRF SystemDC power supplies for the RF generation box in place

[Koji, Steve]

DC power supplies for the RF generation box are now in place. They are the top two of the 6 Sorensens in the OMC short rack next to 1X2.

We made the connections as we did for the RF distribution box, the power supplies labele, and the cables strain-relieved.

The power supply is not yet connected to the actual RF generation box. This should be done by Suresh or someone with the supervision of him.

Note:
We have two +18V supply on the short OMC rack, in total. One is for the RF source, the other is for the OMC PZTs, whitening, etc.
This is to avoid unnecessary ground loop
although the grounding situation of the OMC side is not known to me.

  4740   Wed May 18 17:06:39 2011 SureshUpdateRF SystemDC power supplies for the RF generation box in place

 

I have checked the voltages on the connector.  They are okay and I have plugged in the Sorensen power into the RF Source.  The ground reference for the Sorensens comes from the 1X2 Rack ground reference lines on the south side of the rack. 

I looked for the OMC ground reference. Could not find one on either of the the OMC half racks.

Quote:

[Koji, Steve]

DC power supplies for the RF generation box are now in place. They are the top two of the 6 Sorensens in the OMC short rack next to 1X2.

We made the connections as we did for the RF distribution box, the power supplies labele, and the cables strain-relieved.

The power supply is not yet connected to the actual RF generation box. This should be done by Suresh or someone with the supervision of him.

Note:
We have two +18V supply on the short OMC rack, in total. One is for the RF source, the other is for the OMC PZTs, whitening, etc.
This is to avoid unnecessary ground loop
although the grounding situation of the OMC side is not known to me.

 

  8013   Wed Feb 6 15:39:19 2013 SteveUpdateElectronicsDC power supplies in cabinets

 East arm cabinet E9 and E10

 

Attachment 1: IMG_0066_1.JPG
IMG_0066_1.JPG
  4715   Fri May 13 23:04:58 2011 SureshUpdateRF SystemDC power supply on RF distribution box has been replaced.

[Steve, Koji, Suresh]

   We shifted two Sorensen power supplies from the Auxiliary rack next to 1X2 to 1Y2.  And have installed them there (pic below).  The local ground reference was picked up from the racks ground reference.  A shielded cable with two twisted pairs was used to make a new power cable for the RF rack.  Since we are using three of the four conductors (+18,+28 and ground), one of them is not connected to anything.  This situation can be improved in a future iteration when, for example, we might wish to relocate the Sorensens to a different rack.

   We are still working on changing the power supply to the RF source.  Will complete this early next week

P5130120.JPG

  4716   Sat May 14 14:12:16 2011 KojiUpdateRF SystemDC power supply on RF distribution box has been replaced.

Key points of the power supply installation

  • We followed the grounding configuration for KEPCO except for the signal ground connection
  • AC power supply has been obtained from the local power strip. This also provides chassis earthing (for safety)
  • The chassis is connected to the shieldin of the DC supply cable. The other end should be isolated.
  • The low voltage side of Sorensen's DC outputs are connected in order to share the same reference  level.
  • The ground level is provided from the cross connect. The cable is connected between the cross connect ground to the sorencen.
    Unlike the KEPCO case, this cable does not have the current return, but just is to define the voltage level of those Sorensens.
  • New AC&DC cables have been nicely strain-relieved.

Quote:

[Steve, Koji, Suresh]

   We shifted two Sorensen power supplies from the Auxiliary rack next to 1X2 to 1Y2.  And have installed them there (pic below).  The local ground reference was picked up from the racks ground reference.  A shielded cable with two twisted pairs was used to make a new power cable for the RF rack.  Since we are using three of the four conductors (+18,+28 and ground), one of them is not connected to anything.  This situation can be improved in a future iteration when, for example, we might wish to relocate the Sorensens to a different rack.

   We are still working on changing the power supply to the RF source.  Will complete this early next week

 

Attachment 1: sorensen.png
sorensen.png
  8448   Fri Apr 12 10:33:42 2013 CharlesSummaryISSDC-Coupled ISS Servo Design

General ISS Design

Signals through the ISS are directed as follows:  an error signal is obtained by summing the ~5 V signal from the PD with a -5 V signal from a high precision voltage regulator (which is first filtered with an ~ 30 mHz low-pass Sallen-Key filter).  It is this signal that is processed/amplified by the servo. The output from the servo is then used to drive an AOM (it is not known exactly how this is done and whether or not any preamplifier/extra circuitry is necessary). The resulting modulation, hopefully, reduces fluctuations in the laser intensity incident on the PD, lowering the relative intensity noise.

Servo Design

Almost the entirety of my focus has been directed toward designing the servo portion of the ISS. Speaking in general terms, the currently proposed design consists of stages of active op-amp filters, but now the stages will have internal switches that allow them to switch between ‘flat’ gain buffers and more complicated filters with our desired behavior. Consider some Example Filter Stages where I have demonstrated a typical switching filter with the switch open and closed. When the switch is closed, the capacitor is shorted and we simply have a variable gain buffer (variable in the sense that its gain can be tuned by proper choice of the resistances) with no frequency dependence. When the switch is open, the capacitor introduces a pole at ~100 Hz and a zero at ~1 kHz.

CircuitLab has decent analysis capabilities and attached are plots generated by CircuitLab. The first plot corresponds to a frequency analysis of the voltage gain of op-amp U1 and the ‘flat’ ~20 dBV gain filter with the switch closed and the capacitor shorted. The second plot is the same frequency analysis, but now with op-amp U2 and the filter with the switch open and the capacitor introduced into signal processing. This particular combination of resistors and capacitors produce a DC gain of 60 dBV, a pole at ~100 Hz, a zero at ~10 kHz and high frequency behavior of ~constant gain of 20 dBV. In this simulation, the gain-bandwidth product of the simulated op-amp (the standard op-amp CircuitLab uses) was artificially increased in order to see more ideal behavior in the higher frequency domain.

Switches like the above can be used to add boosts to some initial filter state (which could be like the above or possibly a simple integrator to achieve high DC gain) and change it into a more complex and more useful filter state advantageous for desired noise suppression. Cascades of these switching filters could be used to create very complicated transfer function behavior. No general servo has yet been designed as the exact details of the intensity noise requirements are still being determined.

With regards to the implementation of the switches, some ‘smart’ signal will be used to trigger a switch opening and the boost being introduced to the signal processing. The switches will be opened (open corresponds to adding the boost) in a manner that maintains stability of the servo circuit. Essentially, some sort of time delay or power monitor induced signal (power from the PD output) will be used to modify the servo's behavior.

AOM

How exactly the signal will drive the AOM for correct noise suppression is unknown currently.

 

Attachment 1: Example_Switching_Filter_Transfer_Function_-_Switch_Closed.png
Example_Switching_Filter_Transfer_Function_-_Switch_Closed.png
Attachment 2: Example_Switching_Filter_Transfer_Function_-_Switch_Open.png
Example_Switching_Filter_Transfer_Function_-_Switch_Open.png
  1667   Thu Jun 11 03:15:15 2009 AlbertoUpdateLSCDD Handoff attempts

Pete, Alberto,

tonight we worked on the tuning of the double demod phases for the handoff of the short DOFs control signals.

Only MICH can now undergo the handoff. PRC can't make it.

Basically, we tuned the PD6 demod phase and reduced the offset in PD6_I. Then we tuned the relative gain of PD6_I and PD2_I so that the two open loop transfer function of the control loops would match. We tried that in several ways and several times but without success.

I guess we're missing to do/check something.

  1669   Thu Jun 11 22:14:10 2009 AlbertoUpdateLSCDD Handoff for the Short DOFs completed

This afternoon I tuned the handoff script for the SRC, after that Rob eralier during the day had already adjusted that for PRC. To do that, I followed the procedure in the Wiki.

  • I measured the OL transfer function of the single demod path and of the double demod path and tuned thier gains so that they matched
  • I tuned the double demod pahses of PD_7 and PD_8 in order to reduce the offset in the PD_x_I signals

After that the SRC could get locked with the double demod signals. the open loop transfer function emasurement on the PRC loop showed that it was nearly unstable. Rob reduced a little its gain to improve the stability.

The DD handoff is now working and we can get back to locking the interferometer.

  1436   Fri Mar 27 02:50:54 2009 YoichiUpdateLockingDD demodulation phase suspicious
I noticed that the gain of PD6_Q (before the phase rotation) was 0 whereas PD6_I gain was 15.
This means the demodulation phase of the PD6 had no meaning other than changing the gain.
According to the conlog, it has been zero since March 2nd. I don't know how it happened.

While I was re-adjusting the DD phase, the MC started to unlock frequently (every 10 minutes or so).
MC1 is again drifting a lot (it is getting step-function like alignment changes intermittently).
This practically made it impossible to work on locking. So I decided to fix the MC first.
See Peter's elog entry for the MC work.
  1645   Wed Jun 3 03:22:16 2009 peteUpdateLockingDD handoff

Rana, Alberto, Pete

We have the DD handoff nominally working.  Sometimes, increasing the SRC gain at the end makes MICH get unstable.  This could be due to a non-diagonal term in the matrix, or possibly because the DRM locks in a funky mode sometimes. 

To get the DD handoff working, first we tuned demod phases in order to zero the offsets in the PD signals handed-off-to.  Based on transer function measurements, I set the PRC PD6_I element to 0.1, and set the PD8_I signal to 0, since it didn't seem to be contributing much.  We also commented out the MICH gain increase at the end of the DD_handoff script.

It could still be more stable, but it seems to work most of the time.

 

 

  1675   Tue Jun 16 02:09:31 2009 robUpdateLockingDD handoff finally working

I had trouble getting the SRC handoff from SD to DD to work.  I tried different gains, flipping the PD7 & 8 demod phases by 180 degrees, and messing with the output matrix to reduce cross-couplings in the state with MICH & PRC on DD and SRC on SD.  Eventually I decided to try to make the DRM matrix diagonalization work. 

It does, mostly.  The handoff is now stable, and the loops all have UGFs around 100Hz.  So, tonight anyways, it's possible to run senseDRM and then loadDRMImatrixData.m and run the resulting tdswrite command, and have a working handoff.  I had to eliminate a few PDs (PD5 & PD10) to get it to work properly. 

It would be nice if this script would measure all the PDs and allow individual setting of loop UGFs and measurement frequencies. 

 

 

  1641   Tue Jun 2 02:28:58 2009 peteUpdateLockingDD handoff work

alberto, pete

 

We worked on tuning the DD handoff tonight.  We checked the DD PD alignments and they looked fine.  First I tuned the 3 demod phases to minimize offsets.  Then I noticed that the post-handoff MICH xfer function needed an increase in gain to look like the pre-handoff xfer function (which has a UGF of about 25 Hz).  I increased the MICH PD9_Q gain from 2 to 7 in the input matrix.   But, the handoff to PRC still failed, so tomorrow we will try to find out why.

In the plot, ref0 is before MICH handoff, and ref1 is after MICH handoff.  There is also a PRC trace (before PRC handooff).

 

 

Attachment 1: mich_dd.pdf
mich_dd.pdf mich_dd.pdf
  362   Thu Mar 6 00:17:37 2008 robUpdateLockingDD handoff working
Got the DD (double demod) handoff scripts working tonight, with just the DRMI. So, now acquisition with the single demod signals is working well, and handoffs to all double demod signals using the input matrix ramping worked several times with the scripts. Up next will be more work with the DRM+ARMs.
  4230   Mon Jan 31 07:41:23 2011 AidanUpdateGreen LockingDFD - medm screen

I added an MEDM screen for the DFD to the GREEN screen. It is displayed in the attached screen shot.

This screen is located in: /cvs/cds/rtcds/caltech/c1/medm/c1gfd/C1GFD_DFD.adl

Attachment 1: Screenshot-3.png
Screenshot-3.png
  4232   Mon Jan 31 12:40:38 2011 rana, joeUpdateGreen LockingDFD - medm screen

This is a plot showing the old filters and the new ones we added this morning.

The new ones have a Cheby for AC coupling below 10 Hz and then a 500 Hz LP after the mixer. The LP frequency has been increased so that we can use this signal in a feedback loop to the ETM with a ~100 Hz UGF.

Attachment 1: a.pdf
a.pdf
  4229   Mon Jan 31 07:03:59 2011 AidanSummaryGreen LockingDFD - noise spectra

Quote:

I've had a go at trying to estimate the frequency noise of the digital frequency discriminator (DFD). I input a 234.5Hz (0.5Vpp) signal from a 30MHz function generator into the ADC. The LP output of the DFD measured 234.5Hz. However, this signal is clearly modulated by roughly +/- 0.2Hz at harmonics of 234.5Hz (as you can see in the top plot in the dataviewer screenshot below). So the frequency noise can be estimated as rms of approximately 0.2Hz.

This is supported by taking the spectra of the LP output and looking at the RMS. Most of the power in the RMS frequency noise (above the minimum frequency) comes from the harmonics of the input signal and the RMS is approximately 0.2Hz.

I believe this stems from the rather basic LP filter (three or four poles around 10Hz?) that is used in the LP filter to remove the higher frequency components that exist after the mixing stage. (The currently loaded LPF filter is not the same as the saved one in Foton - and that one won't load at the moment, so I'm forced to remember the shape of the current filter).

 The attached screen capture from data viewer shows the LP_OUT hovering around 234.5Hz.

 Here is the spectrum of the input into the DFD (a 234.5Hz sine wave, 0.5 Vpp) and the spectrum and RMS of the LP output. The linewidth of the input signal is clearly much less than 0.1Hz, where as the RMS noise (above 2mHz) is approximately 0.2Hz and the main contributions are clearly the harmonics of the 234.5Hz signal.

Attachment 1: DFD-bandwidth_noise.pdf
DFD-bandwidth_noise.pdf
  4234   Mon Jan 31 18:25:25 2011 AidanUpdateGreen LockingDFD - results from the new filters (and running with AWG)

Quote:

This is a plot showing the old filters and the new ones we added this morning.

The new ones have a Cheby for AC coupling below 10 Hz and then a 500 Hz LP after the mixer. The LP frequency has been increased so that we can use this signal in a feedback loop to the ETM with a ~100 Hz UGF.

Joe injected a 234.567 etc. Hz sine wave into the excitation channel in the DFD INPUT filter. The spectrum of the output of the LP filter with the new filter is shown below with the RMS calculated from 300Hz down to 1mHz - see first attachment. The RMS is equal to about 2.5Hz. (Incidentally, the RMS is very much higher (slightly less than 400Hz - see second attachment) if you calculate it from 7kHz down to 1mHz). 

Attachment 1: DFD-bandwidth_noise_CLP500_to_300Hz.pdf
DFD-bandwidth_noise_CLP500_to_300Hz.pdf
Attachment 2: DFD-bandwidth_noise_CLP500_to_7000kHz.pdf
DFD-bandwidth_noise_CLP500_to_7000kHz.pdf
  11371   Mon Jun 22 20:59:19 2015 ericqUpdateLSCDFD Delay length

I've been thinking a bit about what the ideal cable length / delay time for the upgraded ALS beatbox should be. Here are some thoughts, but no conclusions yet. 

If you're not running your beatbox mixer in compression, there are two competing effects when you change the cable length. At first, more delay gives better sensitivity, but this does not go on to infinity, because cable attenuation eventually kills your signal. It turns out that the ideal length can be derived to be whatever length gives you 20/ln(10) = -8.7dB of attenuation. Frank found this out in PSL ELOG 825, and I found an HP document that derives this (and other useful DFD math) to the wiki, here.

In PSL ELOG 826, Frank calculated this ideal length for a 160MHz carrier in various kinds of cables. 

However, this is not the end of the story. In the case of the DFD, we actually benefit from operating the mixer in compression, as makes our sensitivity less sensitive to flucuations in the beat amplitude. In this situation, the HP doc states "For maximum sensitivity, more delay can be added until the signal level out of the delay line is 8.7dB below the phase detector (mixer) compression point." I'm not sure I really understand the logic behind this statement, though. 

Lastly, Koji mentioned the fact that the splitter in the demod board does not split at exactly 90 degrees, making the trajectory in the IQ plane an ellipse. This means that if the beat signal is moving around the ellipse a lot, or even wrapping around it, we can suffer from some nonlinear signal conversion. Also, if the raw DFD sensitivity is very high, the free swinging mirrors will cause the signal to swing around faster than the phase tracker can keep up. This should be easy to avoid, however; I doubt we will use so much cable that the beat would move by so much. 

I intend to take all of this into account when picking a cable length! Jessica is going to help us make a nice box for them, too. 

  11374   Wed Jun 24 17:30:45 2015 ericqUpdateLSCDFD Delay length

This afternoon, I had a fruitful conversation with Rich Abbott about various kinds of cables.

I've sent an email to Steve to ask him to buy 2 x 50m LMR-195 cables, with male SMA connectors. Rich highly recommends these for their polyethylene insulation, which makes them less microphonic and less susceptible to thermal expansion, low loss, and multi-ply bonded foil shielding.

50m means that the peak to peak mixer output swing corresponds to about a MHz. 1nV of mixer output noise looks like ~6mHz frequency noise, for a Level 3 mixer appropriately driven. As a comparison, the lowest our in-loop green PDH error signals get is 0.1Hz/rtHz. 

The cable attenuation should be around 4.2dB at 50MHz, and 7.3dB at 150MHz, according to the data sheet. Thus, we should not be in the regieme where we are losing sensitivity to the attenuation. 

By my rough geometric estimation, these two should fit in the 2U box I got ahold of today fine. Jessica is designing the front panel. 

We currently have ~30m of RG-408 and RG-142 as our delay lines. 

  14981   Mon Oct 21 12:25:46 2019 gautamUpdateALSDFD electronics checkout

Summary:

There are no unexpected red-flags in the performance of the DFD electronics. The calibration factors for the digital phase tracker system are 71.291 +/- 0.024 deg/MHz for the X delay line and 70.973 +/- 0.024 deg/MHz for the Y delay line, while the noise floor for the frequency noise discrimination is ~0.5 Hz/rtHz above 1 Hz (dominated by ADC noise).

Details:

  1. Attachment #1 - This observation is what motivated my investigation.
    •  found that for certain beat frequencies between the PSL + EX lasers, the frequency noise reported by the DFD system was surprisingly low.
    • The measurement condition was: EX laser frequency locked to the arm cavity length by the uPDH servo at EX, arm cavity length locked to PSL frequency via POX locking.
  2. To investigate further, I disconnected the output of the NF1611 PDs going to the ZHL-3A amplifiers on the PSL table (after first blocking the PSL light so that the PDs aren't generating any RF output).
    • An RF function generator (IFR2023B) was used to generate an RF signal to mimic the ALS beat signal.
    • I used a power splitter to divide the signal power equally between the two DFD paths.
    • The signal level on the Marconi was set to -5 dBm, to mimic the nominal power level seen by the DFD system.
    • I then performed two tests - (i) to calibrate the Phase Tracker output to deg / MHz and (ii) to measure the frequency noise reported by the DFD system for various signal frequencies.
    • Test (i): sweep the marconi frequency between 10 MHz - 200 MHz, measure the I and Q channels for each phase tracker servo, and figure out the complex argument of the signal using the arctangent. A linear polynomial was fit to the measured datapoints to extract the desired slope.
    • Test (ii): Sample frequencies uniformly distributed between 20 MHz - 80 MHz (nominal range of ALS beat frequencies expected). Reset the phase tracker servo gain, clear the output histories, wait for any transients to die out, and then collect the phase tracker servo output for 1 minute. Compute the FFT to figure out the frequency noise.
    • Attachment #2: Shows the phase tracker calibration, i.e. the results of Test (i). I took this opportunity to update the EPICS calibration fields that convert phase tracker servo output to Hz, the correction was ~7%. These numbers are consistent with what I measured previously - but the updated values weren't registered with SDF so everytime the LSC model was restarted, it reverted to the old values.
    • Attachment #3: Shows the spectra for the various measurements from Test (ii).
    • Attachment #4: Shows the gain of the phase tracker servo as a function of the RF signal frequency. This is a proxy for the signal strength, and the observed trend suggests that the signal power seen after digitization of the demodulated delay line output goes down by ~20% at 80 MHz relative to the level at 20 MHz. Seems reasonable to me, given frequency dependent losses of the intervening electronics / cabling.

Conclusion and next steps:

I still don't know what's responsible for the anomalously low noise levels reported by the ALS-X system sometimes. Next test is to check the EX PDH system, since on the evidence of these tests, the problem seems to be imprinted on the light (though I can't imagine how the noise becomes lower?).

Attachment 1: ALSnoiseAnomaly.pdf
ALSnoiseAnomaly.pdf
Attachment 2: DFDcalib.pdf
DFDcalib.pdf
Attachment 3: spectra.pdf
spectra.pdf
Attachment 4: PTgains.pdf
PTgains.pdf
  13886   Thu May 24 13:06:17 2018 gautamConfigurationALSDFD noises

Summary:

  1. The DFD noise floor is ~0.5Hz/rtHz at 100Hz (see Attachment #2).
  2. I cannot account for the measured noise floor of the DFD system. The Marconi noise and the AA noise contributions should be neglibible at 100Hz.
  3. This SURF report would lead me to believe that the delay line cable length is 50m. But my calibration suggests it is shorter, more like 40m (see Attachment #1). I had made some TF measurements of the delay sometime ago, need to dig up the data and see what number that measurement yields.

Details and discussion: (diagrams to follow)

  • Delay line linearity was checked by driving the input with Marconi, waiting for any transient to die down, and averaging the I and Q inputs to the phase tracker servo (after correcting for the daughter board TF) for 10 seconds. The deg/MHz response was then calculated by trigonometry. Not sure what to make of the structure in the residuals, need to think about it.
  • DFD noise was checked by driving the DFD input with a Marconi at 50MHz, RF level = 8dBm, which are expected parameters for nominal ALS operation. In this configuration, I measured the spectrum of the phase tracker output. I then used the calibration factor from the above bullet to convert to Hz/rtHz.
  • The electronics noise contribution of the daughter board was calibrated to Hz/rtHz by using the Marconi to drive the DFD input with a known FM signal (mod depth ~0.05), and using the SR785 to measure the power of the FM peak. This allows one to back out the V/Hz calibration constant of the delay line. I tweaked the carrier frequency until the ratio of power in I channel to Q channel (or the other way around) was >20dB before making this measurement.
  • I have no proof - but I suspect that the whole host of harmonics in the noise spectrum is because the 1U AA chassis sits directly on top of some Sorensen power supplies. These Sorensens power the frequency distribution box in the LSC rack, so the simplest test to confirm would be to turn off the RF chain, and then Sorensens, and see if the peaky features persist.
Attachment 1: DFDcalib.pdf
DFDcalib.pdf
Attachment 2: DFD_NB.pdf
DFD_NB.pdf
  13890   Thu May 24 20:31:03 2018 gautamConfigurationALSDFD noises

A couple of months ago, I took 21 measurements of the delay line transfer function. As shown in Attachment #2, the unwrapped phase is more consistent with a cable length closer to 45m rather than 50m (assuming speed of light is 0.75c in the cable, as the datasheet says it is).

Attachment #1 shows the TF magnitude for the same measurements. There are some ripples consistent with reflections, so something in this system is not impedance matched. I believe I used the same power splitter to split the RF source between delayed and undelayed paths to make these TFs as is used in the current DFD setup to split the RF beatnote.

Quote:
 

I had made some TF measurements of the delay sometime ago, need to dig up the data and see what number that measurement yields.

Attachment 1: TF_X_mag.pdf
TF_X_mag.pdf
Attachment 2: TF_X_phase.pdf
TF_X_phase.pdf
  14470   Mon Feb 25 20:20:07 2019 KojiUpdateSUSDIN 41612 (96pin) shrouds installed to vertex SUS coil drivers

The forthcoming Acromag c1susaux is supposed to use the backplane connectors of the sus euro card modules.

However, the backplane connectors of the vertex sus coil drivers were already used by the fast switches (dewhitening) of c1sus.

Our plan is to connect the Acromag cables to the upper connectors, while the switch channels are wired to the lower connector by soldering jumper wires between the upper and lower connectors on board.

To make the lower 96pin DIN connector available for this, we needed DIN 41612 (96pin) shroud. Tyco Electronics 535074-2 is the correct component for this purpose. The shrouds have been installed to the backplane pins of the coil driver circuit D010001. The shroud has the 180deg rotation dof. The direction of the shroud was matched with the ones on the upper connectors.

Attachment 1: P_20190222_175058.jpg
P_20190222_175058.jpg
  14877   Fri Sep 13 13:03:35 2019 KojiSummaryCDSDIN 96pin to DSUB37 adapter (single) ready for use

The PCB board of the adapter for DIN 96pin to DSUB37 conversion (single DSUB version) was delivered yesterday and I quickly soldered the connectors.

They are ready for use and stored in a JLCPCB cardboard box on a pile of acromag stuff. (Note that the lacel is written on the box with Sharpie)

Attachment 1: P_20190912_192109.jpg
P_20190912_192109.jpg
  14879   Mon Sep 16 09:11:37 2019 gautamSummaryCDSDIN 96pin to DSUB37 adapter (single) ready for use

I installed 6 of these in 1Y2. Three were for PD INTF #1-3, and I used three more for the AS110, REFL11, and REFL33 Demod board FEs, where the strain-reflief of the DC power cables to the Eurocrate was becoming a problem. So now there are only 4 units available as spares.

Once the strain-relieving of the Dsub cabling to 1Y3 is done, we can move ahead with testing. I'd like to put this to bed this week if possible.

  15635   Tue Oct 20 20:12:18 2020 KojiSummaryGeneralDJI OSMO Pocket Camera Kit

I set up an action cam (DJI OSMO Pocket) and brought it back to the 40m. The kit is now placed in the control room cabinet together with the Canon DSLR.

I might have left the USBC chaging cable at home this time. Will bring it back next time.-> The cable was returned to the kit on Oct 23rd.

Attachment 1: 20201020200929_IMG_0173.JPG
20201020200929_IMG_0173.JPG
  170   Wed Dec 5 19:25:07 2007 ranaDAQCDSDMF
I made a database file on C1AUX called dmf.db. It has 9 DMF EPICS channels which are also trended
so that one can now write data to those channels from a DMF Monitor and the data will be records.

New channels:
[C1:DMF-SEIS_1]
[C1:DMF-SEIS_2]
[C1:DMF-SEIS_3]
[C1:DMF-LINE_1]
[C1:DMF-LINE_2]
[C1:DMF-LINE_3]
[C1:DMF-MC_1]
[C1:DMF-MC_2]
[C1:DMF-MC_3]

I added these to C1AUX because it doesn't do much and can be booted without having much effect.
(it controls Mech Shutters, Video, and Illuminators. It used to also do the EO Shutter but I
removed that from its startup.cmd and it will no longer load those records).
  1392   Thu Mar 12 00:29:39 2009 JenneOmnistructureDMFDMF being whiny again

Quote:
The seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running.


[Yoichi, Jenne]

seisBLRMS was down again. I assumed it was just because the DMF Master Enable was in the 'Disabled' state, but enabling it didn't do the trick. Rana's green terminal window was complaining about not being able to find nodus.ligo.caltech.edu. Yoichi and I stopped it, closed and restarted Matlab, ran mdv_config, then ran seisBLRMS again, and it seems happy now.

On the todo list still is making the DMF / seisBLRMS stuff happy all the time.
  316   Thu Feb 14 15:04:53 2008 robDAQDMFDMF delay

Sometime ago I edited seisBLRMS to keep of track of how long it was taking to write RMS data (that is, the delay between the accelerometer data and the write of the EPICS rms data). Here's a plot of that info, showing how the delay increases over time. I think this indicates a logical flaw in the timing of the seisBLRMS program, which sort of relies on everything running well consistently; this should not be difficult to fix. I'll maybe try increasing the delay to ~10 minutes, and making it relatively inflexible.
Attachment 1: DMFdelay.png
DMFdelay.png
  1484   Wed Apr 15 02:20:46 2009 rana, yoichiUpdateDMFDMF now working copy

We found that DMF/ was not an SVN working copy, so I wiped out the SVN version, imported the on-disk copy, moved it to DMFold/ and then checked out the SVN version.

We can delete DMFold/ whenever we are happy with the SVN copy.

  1977   Tue Sep 8 19:36:52 2009 JenneOmnistructureDMFDMF restarted

I (think I) restarted DMF.  It's on Mafalda, running in matlab (not the complied version which Rana was having trouble with back in the day).  To start Matlab, I did "nohup matlab", ran mdv_config, then started seisBLRMS.m running.  Since I used nohup, I then closed the terminal window, and am crossing my fingers in hopes that it continues to work.  I would have used Screen, but that doesn't seem to work on Mafalda.

  1979   Tue Sep 8 20:25:03 2009 JenneOmnistructureDMFDMF restarted

Quote:

I (think I) restarted DMF.  It's on Mafalda, running in matlab (not the complied version which Rana was having trouble with back in the day).  To start Matlab, I did "nohup matlab", ran mdv_config, then started seisBLRMS.m running.  Since I used nohup, I then closed the terminal window, and am crossing my fingers in hopes that it continues to work.  I would have used Screen, but that doesn't seem to work on Mafalda.

 Just kidding. That plan didn't work.  The new plan: I started a terminal window on Op540, which is ssh-ed into Mafalda, and started up matlab to run seisBLRMS.  That window is still open. 

Because Unix was being finicky, I had to open an xterm window (xterm -bg green -fg black), and then ssh to mafalda and run matlab there.  The symptoms which led to this were that even though in a regular terminal window on Op540, ssh-ed to mafalda, I could access tconvert, I could not make gps.m work in matlab.  When Rana ssh-ed from Allegra to Op540 to Mafalda and ran matlab, he could get gps.m to work.  So it seems like it was  a Unix terminal crazy thing. Anyhow, starting an xterm window on Op540m and ssh-ing to mafalda from there seemed to work.

Hopefully this having a terminal window open and running DMF will be a temporary solution, and we can get the compiled version to work again soon.

  1230   Thu Jan 15 22:30:32 2009 ranaConfigurationDMFDMF start script
I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280

it didn't work Frown
  1232   Fri Jan 16 11:33:59 2009 robConfigurationDMFDMF start script

Quote:
I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280

it didn't work Frown


It should work soon. The PATH on mafalda does not include ".", so I added a line to the start_DMF subscript, which sets up the DMF ENV, to prepend this to the path before starting the tools. I didn't put it in the primary login path (such as in the .cshrc file) because Steve objects on philosophical grounds.

Also, the epics tools in general (such as tdsread) on mafalda were not working, due to PATH shenanigans and missing caRepeaters. Yoichi is harmonizing it.
  1461   Wed Apr 8 18:46:50 2009 ranaConfigurationGeneralDMF, SVN, x2mc, and matlab

While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.

Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.

We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.

Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.

I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.

  15909   Fri Mar 12 03:23:37 2021 KojiUpdateBHDDO card (DO-32L-PE) brought from WB

I've brought 4 DO-32L-PE cards from WB for BHD upgrade for Jon.

Attachment 1: P_20210311_232742.jpg
P_20210311_232742.jpg
Attachment 2: P_20210311_232752.jpg
P_20210311_232752.jpg
  7005   Mon Jul 23 18:16:13 2012 JamieUpdateSUSDQ block added to sus_single_control library parts

I have added a DQ block to the sus_single_control library part.  This means that all sus models will automatically generate DQ channels based on what is specified in this doc block:

#DAQ Channels

SUSPOS_IN1
SUSPIT_IN1
SUSYAW_IN1
SUSSIDE_IN1
ULSEN_OUT
URSEN_OUT
LRSEN_OUT
LLSEN_OUT
SDSEN_OUT
OLPIT_IN1
OLYAW_IN1
OLSUM_IN1

So for instance, for BS will have the following DQ channels:

C1:SUS-BS_SUSPOS_IN1_DQ
C1:SUS-BS_SUSPIT_IN1_DQ
...

etc.  The channels names modified by the activateDQ.py script after install are still modified appropriately.

This is now the place where we should be maintaining DQ channels.

  231   Thu Jan 10 00:12:01 2008 tobinSummaryLockingDR
[John, Tobin, Rana]

1. We found SUS_BS_SENSOR_UL to have a ratty signal and low DC value. Twiddling the cables at the BS satellite amplifier and vacuum feedthrough brought the signal back (to 0.667V), but it is still spiky, spiking up to a couple times per second. Rana suggested that these spikes might be scattered YAG laser light (as hypothesized in August). The spikes go away when we misalign the PRM or either ITM, and when we unlock the mode cleaner, lending credance to this theory. SUS_BS_SENSOR_UR also spikes, but much less frequently. We turned off C1:SUS-BS_ULSEN_SW2 and continued.

2. After dither alignment the oplev beams were centred and we were able to lock DRM plus either arm reliably (however locking in this state broke ./drstep_bang at the first ``Going DD''). We ran scripts/DRFPMI/bang/nospring/drdown_bang and were subsequently able to lock DRFPMI (i.e., full IFO) a couple times.

3. To do: Debug ./drstep_bang with just the DRM (no arms).
  12069   Mon Apr 11 16:06:30 2016 ericqUpdateLSCDRFPMI Data Archived

I have copied over the complete frame files from two DRFPMI lock acquisitions + locks to /frames/archive. The data should be safe from the wiper script here.

One, under the subfolder DRFPMI_Mar29_cal is the lock where the CAL-DARM channel is properly calibrated at GPS time 1143274087.

The other lock, under DRFPMI_MAR29_nocal, does not have the calibration set up yet, but was a much quicker acquistion (<2 min from ALS acquisition to DRFPMI) and longer lock (~8min).

  12053   Tue Mar 29 03:16:21 2016 ericqUpdateLSCDRFPMI Locked Once More

[ericq, Gautam]

Three RF-only locks longer than a minute tonight, out of 5 total attempts. 

Last week, I determined that the beam spot on the RF POP PD is too large. This still needs to be fixed. I updated the ASS model to use REFLDC as a PRCL dither error signal; it works. 

There seems to be some excess angular motion of ETMY tonight. This is evident in the oplev spectra (as compared to ETMX), and the GTRY camera, and even the retroreflected beam from a misalgined ETMY on the ITMY face when the PRC is carrier locked.

Gautam and I mostly focused on setting up the CAL-DARM_CINV block to produce this (mostly) calibrated spectrum starting from GPS 1143274087. [Darm on unwhitened AS55, DRMI on 3F, one CARM boost]

Here are the control and error signal spectra:

[DTT files attached]

Note to self: archive some of this data 

Attachment 1: 2016-03-29_calibdarm.pdf
2016-03-29_calibdarm.pdf
Attachment 2: 2016-03-29_DRFPMI_errctrl.pdf
2016-03-29_DRFPMI_errctrl.pdf
Attachment 3: DRFPMI_DTT.zip
  11691   Thu Oct 15 03:08:57 2015 ericqUpdateLSCDRFPMI Locked for 20 sec

[ericq, Gautam]

For real this time.

Attachment 1: DRFPMI_locked.pdf
DRFPMI_locked.pdf
  11692   Thu Oct 15 04:14:14 2015 ericqUpdateLSCDRFPMI Locked for 20 sec

Fast ALS was still a problem tonight. I don't think high frequency ALS noise saturating the PC drive is the issue; I put two 10k poles before the CM board (shooting for just 2-3kHz bandwidth), and the PC drive levels would be stable and low up until the lockloss, which was always conincident with a step in the AO gain.

After working with that for a few hours, we turned back to our more standard locking attempts. First, we dither aligned the PRMI, and then centered the REFL beam on REFL11. It's hard to say for certain, but we may have been a little close to the edge of the PD. The only other thing that differed from Monday's attempts was using 6dB less AO gain when trying the up the overall gain. 

The script now reliably breaks through to stable high powers, we had a handful of pure-RF locks tonight. The digital DARM gain needs tuning, and the CARM bandwidth still isn't at its final state, but these are very tractable. Off the top of my head, the way forward now includes:

  • Set proper final DARM loop shape
  • Set final CARM loop shape
  • Take full sensing matrix
  • Make 1F handoff
  • Set up the CAL model to produce (at least roughly) calibrated spectra
  • measure noise couplings and other fun stuff

Unrelated: I feel that the PRC angular FF may have deteriorated a bit. I'm leaving the PRC locked on carrier to collect data for wiener filter recalculation. 

  11693   Thu Oct 15 10:59:12 2015 KojiUpdateLSCDRFPMI Locked for 20 sec

Great job!
Many thanks Eric, Gautam, and all the current and past colleagues
for your tremendous contributions to bring the 40m to this achievement.

  11696   Sat Oct 17 18:55:07 2015 ranaUpdateLSCDRFPMI Locked for 20 sec

smiley in addition to Koji's words I feel like we should also thank those who made small but positive contributions. Its hard not to notice that this locking only happened after the new StripTool PEM colors were implemented...

From the times series plot I guess that the fuzz of the in-loop DARM is 1 pm RMS (based on memory). This means that the ALS was holding the DARM at 10 pm from the RF resonances.

There is no significant shift in the DRMI error signals, so new weird CARM effect. Would be interesting to see what the 1f signals do in the last 60 seconds before RF lock.

For documentation, perhaps Gautam can post the loop gain measurements of the 5 loops on top of the Bode plots of the loop models.

  12028   Thu Mar 10 03:03:11 2016 ericqUpdateLSCDRFPMI Power stable, but no RF handoff

[ericq, Gautam]

We worked on getting the DRFPMI back up and running, hoping the ALS performance was good enough. 

We did succeed in bringing in enough of the AO path to stabilize arm powers > 100, but failed at the full RF DARM handoff. 

REFL165 angle was adjusted to -86 to minimize PRCL in the Q signal. 

The AS110 signals are mysteriously huger than they used to be. Whitening gain reduced to 15dB from 27dB. Old trigger thresholds are still fine.

The new AUX X laser has a different sign for the temperature-> frequency coupling, so our usual convention of "beatnote goes up when temp slider goes up" meant the ALSX input matrix elements had to change sign.

We think the POPDC PD (which I think is the POP2F PD) may be miscentered, since in PRMI configuration, its maximum does not coincide with the REFLDC minimum, and leaves a sizeable TEM10 lobe on the REFL camera. This was a pain. 

  11669   Tue Oct 6 03:30:17 2015 ericqUpdateLSCDRFPMI Progress

[ericq, Gautam]

Highlight of the night: the DRFPMI was held at arm powers > 110 for 20 seconds. ALS feedback was still running though, but so was some nonzero REFL11 AO path action.

In short, time was spent finding the right FM trigger settings to keep the DRMI locked while CARM is fluctuating through resonance, what CARM offset to acquire DRMI lock at, order of operations of turning on AO / turning up overall CARM gain, etc. 

Sadly, for the past hour or so, the DRMI has refused to stay locked for more than ~20 seconds, so I haven't been able to push things much further. This is a shame, since I'm very nearly at the equivalent point in the PRFPMI locking script where the ALS control is turned off completely. 

  11671   Thu Oct 8 04:48:50 2015 ericqUpdateLSCDRFPMI Progress

Progress was made. CARM was stably locked on RF only. DARM was RF only for a few moments before I typed in a wrong number...

A change was made to the LSC model's triggering section to make the DRMI hold more reliably at zero CARM offset. Namely, the POPDC signal now has its absolute value taken before the trigger matrix. Even unwhitened, it occaisionally would somehow go negative enough to break the DRMI trigger.

AUX X laser was acting up again. As before, tweaking laser current is the temporary fix.

  11672   Thu Oct 8 13:13:20 2015 KojiUpdateLSCDRFPMI Progress

Please clarify: I wonder if you were at the zero offset for CARM and DARM or not. I am 25% excited right now.

  11673   Thu Oct 8 14:14:50 2015 ericqUpdateLSCDRFPMI Progress
Quote:

Please clarify: I wonder if you were at the zero offset for CARM and DARM or not. 

Yes, this was at the full DRFPMI resonance.

  11674   Thu Oct 8 16:48:23 2015 KojiUpdateLSCDRFPMI Progress

Awesome

ELOG V3.1.3-