40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 54 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  1519   Fri Apr 24 17:26:57 2009 YoichiUpdateLockingDARM demod phase

Quote:

There's actually code in place in the LSC to dynamically adjust the demod phase for AS1. I've never made much use of it, because it's possible to get around the problem with some gain tweaking if you start at the right phase, or because I did the DC readout handoff earlier.

Attached is a cartoon showing how the demod phase at the dark port changes as the CARM offset is decreased.


The cartoon is very nice.
I actually changed the demod phase continuously as the CARM offset was reduced to get up to arm power = 70.
As the CARM offset is changed, not only the DARM signal gain but also the phase margin around 100Hz changes if you use a fixed demodulation phase.
So it was necessary to change the demodulation phase to keep the DARM loop stable.
  10621   Fri Oct 17 03:05:00 2014 ericqUpdateLSCDARM locked on DC Transmission difference

 I've been able to repeatedly get off of ALS and onto (TRY-TRX)/(TRY+TRX). Nevertheless, lock is lost between arm powers of 10 and 20. 

I do the transition at the same place as the CARM->SqrtInv transition, i.e. arm powers about 1.0 Jenne started a script for the transition, and I've modified it with settings that I found to work, and integrated it into the carm_cm_up script. I've also modified carm_cm_down to zero the DARM normalization elements. 

I was thwarted repeatedly by the frequent crashing of daqd, so I was not able to take OLTFs of CARM or DARM, which would've been nice. As it was, I tuned the DARM gain by looking for gain peaking in the error signal spectrum. I also couldn't really get a good look at the lock loss events. Once the FB is behaving properly, we can learn more. 

Turning over to difference in transmission as an error signal naturally squashes the difference in arm transmissions:

TRdifflock.png


I was able to grab spectra of the error and control signals, though I did not take the time to calibrate them... We can see the high frequency sensing noise for the transmission derived signals fall as the arm power increases. The low frequency mirror motion stays about the same. 

Oct17lock.pdf


So, it seems that DARM was not the main culprit in breaking lock, but it is still gratifying to get off of ALS completely, given its out-of-loop-noise's strong dependence on PSL-alignment. 

  10737   Wed Nov 26 22:24:28 2014 JenneUpdateLSCDARM loop improved, other work

[Jenne, Koji]

We have done several things this evening, which have incrementally helped the lock stability.  We are still locking CARM and DARM on ALS, and PRMI on REFL165.

  • Saw peaks in CARM error signal at 24Hz and 29 Hz, so put in moderate-Q resonant gains. 
  • DARM at low frequency was much noisier than CARM.  We discovered that we had put in a nice boost at some point for CARM in FM1, but hadn't transferred that over to DARM.  Copying FM1 from CARM to DARM (so replacing an integrator with a boost below ~10Hz) dropped the DARM noise down to match the CARM noise at low frequencies.
  • Koji noticed that we were really only illuminating one quadrant of the Xend QPD, so we aligned both trans QPDs.  Also, I reset the transmission normalization so that all 4 diodes (Thorlabs and QPDs at each end) all read 1 with good alignment.
  • We've got some concerns about the ASS.  It needs some attention and tuning.
    • The X ASS needs an overall gain of about 0.3.  This may be because I forgot to put the new lower gains into the burt restore after Rana's oplev work, or this may be something new.
    • When Koji did a very careful arm alignment, we turned on the Y ASS and saw it methodically reduce the transmitted power.  Mostly it was moving ETMY in yaw.  Why is the DC response of the ASS not good?  The oplev work shouldn't have affected DC.
    • We don't like the way the ASS offloads the alignment.  Maybe there's a better way to do it overall, but one thought is to have an option to offload (for long-term alignment fixing, so maybe once a day) and another option to just freeze the current output (for the continual tweak-ups that we do throughout the evening).  We'd want the ASS to start up again with these frozen values, and not clear them.
  • ETMY was being fussy, in the same way that ETMX had been for the last few months.  I went down to squish the cables, and found that it was totally not strain-relieved, and that the cable was pulling on the connector.  I have zip tied the cable to the rack so that it's not pulling anymore.
  • At high arm powers, it is hard to see what is going on at the AS port because there is so much light.  Koji has added an ND filter to the AS camera so that we can more easily tweak alignment to improve the contrast.

Something that has been bothering me the last few days is that early in the evening, I would be able to get to very high arm powers, but later on I couldn't.  I think this has to do with setting the contrast at the AS port separately for the sideband versus the carrier.  I had been minimizing the AS port power with the arms held off resonance, PRMI locked.  But, this is mostly sideband.  If instead I optimize the Michelson fringes when the arms are held with ALS at arm powers of 1, and PRM is still misaligned, I end up with much higher arm powers later.  Some notes about this though:  most of this alignment was done with the arm cavity mirrors, specifically the ETMs, to get the nice Michelson fringes.  When the PRM is restored and the PRMI locked, the AS port contrast doesn't look very good.  However, when I leave the alignment alone at this point, I get up to arm powers above 100, whereas if I touch the BS, I have trouble getting above 50.


Around GPS time 1101094920, I moved the DARM offset after optimizing the CARM offset.  We were able to see a pretty nice zero crossing in AS55, although that wasn't at the same place as the ALS diff zero offset (close though).  At this time, the arm powers got above 250, and TRY claimed almost 200.  These are the plots below, first as a wide-view, then zoomed in.  During this time, PRCL still has a broadband increase in noise when the arm powers are high, and CARM is seeing a resonance at a few tens of Hz.  But, we can nicely see the zerocrossing in AS55, so I think there's hope of being able to transition DARM over. 

DARMcrossing_Power.png

DARMcrossing_ErrCtrl.png

DARMcrossing_AuxErr.png

DARMcrossing_Angles.png

Now, the same data, but zoomed in more.

DARMcrossing_Power_Zoom.png

DARMcrossing_ErrCtrl_Zoom.png

DARMcrossing_AuxErr_Zoom.png

DARMcrossing_Angles_Zoom.png


During the 40m meeting, we had a few ideas of directions to pursue for locking:

  • Look into using POX or POY as a proxy for POP and instead of REFL, for CARM control.  Maybe we have some nice juicy SNR.
  • Check the linearity of our REFL signals by holding the arms on (or close to) resonance, then do a swept sine exciting CARM ctrl and taking a transfer function to the RF signals.
  • Q is going to look into the TRX QPD, since he thought it looked funny last week, although this may no longer be necessary after we put the beam at the center of the QPD.
  • Koji had a thought for making it easier to blend the CARM error signals.  What if we put a pole into the ALS CARM signals at the place where the final coupled cavity pole will be, and then compensate for this in the CARM loop.  Since any IR signals will naturally have this pole, we want the CARM loop to be stable when it's present.
  • Diego tells us that the Xarm IR beatnote is basically ready to go.  We need to see how big the peak is so we can put it into the frequency counter and read it out via EPICS.  The freq counter wants at least -15dBm, so we may need an amplifier.
  15350   Tue May 26 02:37:19 2020 gautamUpdateLSCDARM loop measurement and fitting

Summary:

In order to estimate the free-running DARM displacement noise, I measured the DARM OLTF using the usual IN1/IN2 prescription. The measured data was then used to fit some model paramters for a loop model that can be used over a larger frequency range.

Details:

  • Attachment #1 shows an overlay of the measured and modelled TFs.
  • Attachment #2 shows the various components that went into building up this model. 
    • The digital AA and AI filter coefficients were taken from the RTCDS code.
    • The analog AA and AI filter zpks were taken from here and here respectively.
    • CDS filters taken from the banks enabled. The 20Hz : 0Hz z:p filter in the CARM_B path is also accounted for, as have the violin-mode notches.
    • Pendulum TF is just 1/f^2, the overall scaling is unimportant because it will be fitted (in combination with the overall scaling uncertainty on the DC optical gain), but I used a value of 10 nm/f^2 which should be in the right ballbark.
    • The optical gain includes the DARM pole at ~4.5 kHz for this config.
  • With all these components, to make the measurement and fit line up, I added two free parameters - an overall gain, and a delay. 
    • NLSQ minimizer was used to find the best-fit values for these parameters.
    • I'm not sure what to make of the relatively large disagreement between measurement and model below 100 Hz - I'm pretty sure I got all the CDS filters included...
    • Moreover, I don't have a good explanation for why the best-fit delay is 400 us. One RTCDS clock cycle is onyl 60 us, and even with an extra clock cycle for the RFM transfer, I still can't get up to such a high delay...

In summary, the UGF is ~150 Hz and phase margin is ~30 deg. This loop would probably benefit from some low-pass filter being turned on.

  10864   Wed Jan 7 09:44:33 2015 ericqUpdateLSCDARM phase budget

As Jenne mentioned, I created a model of the DARM OLG to see why we have so little phase margin. However, it turns out I can explain the phase after all.

Chris sent me his work for the aLIGO DARM phase budget, which I adapted for our situation. Here's a stacked-area plot that shows the contributions of various filters and delays on our phase margin, and a real measurement from a few days ago . 

DarmPhaseBudget.pdf

This isn't so great! Informed by Chris's model, the digital delays look like: (Here I'm only listing pure delays, not phase lags from filters)

  • 64k cycle (End IOP)
  • 16k cycle (End isce[x/y])
  • 16k cycle x 2 (end to LSC through RFM) [See ELOG 10811]
  • 16k cycle (LSC)
  • 16k cycle (LSC to SUS through dolphin) [See ELOG 9881]
  • 16k cycle (SUS)
  • 16k cycle x2 (SUS to end through RFM)
  • 16k cycle (End isce[x/y])
  • 64k cycle (SUS IOP)
  • DAC zero order hold

This adds up to about 570usec, 20.5 degrees at 100Hz, largely due to the sheer number of computer hops the transmission loops involve. 

As a check, I divided the measured OLG by my model OLG, to see if there is any shape to the residual, that my model doesn't explain. It looks like it fits pretty well. Plot:

 DarmOLGresidual.pdf

So, unless we undertake a bunch of computer work, we can only improve our transmission loops through our control filter design. 

Everything I used to generate these plots is attached. 

  10868   Wed Jan 7 13:39:42 2015 ChrisUpdateLSCDARM phase budget

I think the dolphin and RFM transit times are double-counted in this budget. As I understand it, all IPC transit times are already built in to the cycle time of the sending model. That is, the sending model is required to finish its computational work a little bit early, so there's time left to transmit data to the receivers before the start of the next cycle. Otherwise you get IPC errors. (This is why the LSC models at the sites can't use the last ~20 usec of their cycle without triggering IPC errors. They have to allow that much time for the RFM to get their control signals down the arms to the end stations.)

For instance, the delay measurement in elog 9881 (c1als to c1lsc via dolphin) shows only the c1lsc model's own 61 usec delay. If the dolphin transfer really took an additional cycle, you would expect 122 usec.

And in elog 10811 (c1scx to c1rfm to c1ass), the delay is 122 usec, not because the RFM itself adds delay, but because an extra model is traversed.

Bottom line: there may still be some DARM phase unaccounted for. And it would definitely help to bypass the c1rfm model, as suggested in 9881.

  1575   Tue May 12 01:11:55 2009 YoichiUpdateLSCDARM response (DC Readout)
I measured the DARM response with DC readout.

This time, I first measured the open loop transfer function of the X single arm lock.
The open loop gain (Gx) can be represented as a product of the optical gain (Cx), the filter (Fx), and the suspension response (S), i.e. Gx = Cx*Fx*S.
We know Fx because this is the transfer function of the digital filters. Cx can be modeled as a simple cavity pole, but we need to know the finesse to calculate it.
In order to estimate the current finesse of the XARM cavity, I ran the armLoss script, which measures the ratio of the reflected light power between the locked and the unlocked state. Using this ratio and the designed transmissivity of the ITMX (0.005), I estimated the round trip loss in the XARM, which was 170 ppm. From this number, the cavity pole was estimated to be 1608Hz.
Using the measured Gx, the knowledge of Fx and the estimated Cx, I estimated the ETMX suspension response S, which is shown in the first attachment.
Note that this is not a pure suspension response. It includes the effects of the digital system time delay, the anti-imaging and anti-aliasing filters and so on.

Now the DARM open loop gain (Gd) can also be represented as a product of the optical gain (Cd), the filter (Fd) and the suspension response (S).
Since the actuations are applied again to the ETMs and we think ETMX and ETMY are quite similar, we should be able to use the same suspension response as XARM for DARM. Therefore, using the knowledge of the digital filter shape and the measured open loop gain, we can compute the DARM optical gain Cd.
The second attachment shows the estimated DARM response along with an Optickle prediction.
The DARM loop gain was measured with darm_offset_dc = 350. Since we haven't calibrated the DARM signal, I don't know how many meters of offset does this number correspond to. The Optickle prediction was calculated using a 20pm DARM offset. I chose this to make the prediction look similar to the measured one, though they look quite different around the RSE peak. The input power was set to 1.7W in the Optickle model (again this is just my guess).

It looks as if the measured DARM response is skewed by an extra low pass filter at high frequencies. I don't know why is it so.
  11606   Wed Sep 16 15:04:33 2015 ericqSummaryLSCDC PD Whitening Board Fixed
Quote:

Tonight we noticed that the REFL_DC signal has gone bipolar, even though the whitening gain is 0 dB and the whitening filter is requested to be OFF.

Fixed! I noticed that whitening gain changes weren't having any effect on CM_SLOW. I then checked REFL_DC, where this also seemed to be the case. Since the gain is controlled via VME machine, and whitening filter switching is controlled via RCG, I figured there must be something wrong with the board. I checked all of the DC PD signals, which share a whitening filter board, and they all had the same symptoms. 

I went and peeked at the board, and it turns out the backplane cable had fallen off. frown

I plugged it in, things look ok. 

  10872   Wed Jan 7 15:53:01 2015 JenneUpdateLSCDC PD analog settings exposed

I have added another block to the LSC screen (and made the corresponding sub-screen) to expose the analog settings for the DC photodiodes. 

Note that we have 2 open channels there, which are still called something like "PD2" and "PD3" from olden times.

If we ever chose to use those, we will probably want to change their names, in /cvs/cds/caltech/target/c1iscaux2/LSC_aux2.db and /cvs/cds/caltech/target/c1iscaux/LSC_aux.db

  12710   Fri Jan 13 08:54:32 2017 JohannesUpdateGeneralDC PD installed

I installed a DC PD (Thorlabs PDA 520) in the beam path to AS55. I placed a 2" 90/10 BS on a flip mount that picks of enough light for the PD to spit out ~8V when the port is bright. Single arm continuous signal will be ~2V. While most of the light still continues towards AS55, the displacement from the BS moves the beam off AS55, so I used the flip mount in case anyone needs to use AS55. The current configuration is UP.

When we're done with loss investigations the flip mount should be removed from the bench.

I hooked the PD up to an ethernet-enabled scope and started scripting the loss map measurement (scope can receive commands via http so we can automate the data acquisition). The scope that was present at the bench and had been used for the MC ringdown measurements had a 'scrambled' screen that I couldn't fix so I had to retrieve another scope ("scope1"). I'll try to find out what's wrong with it but we may have to send it in for repair.

 

  16150   Fri May 21 00:15:33 2021 KojiUpdateElectronicsDC Power Strip delivered / stored

DC Power Strip Assemblies delivered and stored behind the Y arm tube (Attachment 1)

  • 7x 18V Power Strip (Attachment 2)
  • 7x 24V Power Strip (Attachment 2)
  • 7x 18V/24V Sequencer / 14x Mounting Panel (Attachment 3)
  • DC Power Cables 3ft, 6ft, 10ft (Attachments 4/5)
  • DC Power Cables AWG12 Orange / Yellow (Attachments 6/7)

I also moved the spare 1U Chassis to the same place.

  • 5+7+9 = 21x 1U Chassis (Attachments 8/9)

 

  2056   Tue Oct 6 01:41:20 2009 robUpdateLockingDC Readout

Lock acquisition working well tonight.  Was able to engage CM boost (not superboost) with bandwidth of ~10kHz.  Also succeeded once in handing off DARM to DC readout.

  1544   Tue May 5 05:16:12 2009 YoichiUpdateLockingDC Readout and DARM response
Tonight, I was able to switch the DARM to DC readout a couple of times.
But the lock was not as stable as the RF DARM. It lost lock when I tried to measure the DARM loop gain.

I also measured DARM response when DARM is on RF.
The attached plot shows the DARM optical gain (from the mirror displacement to the PD output).
The magnitude is in an arbitrary unit.

I measured a transfer function from DARM excitation to the DARM error signal. Then I corrected it for the DARM open loop gain and the pendulum response to get the plot below.

There is an RSE peak at 4kHz as expected. The origin of the small bump and dip around 2.5kHz and 1.5kHz are unknown.
I will consult with the Optickle model.
I don't know why the optical gain decreases below 50Hz (I don't think it actually decreases).
Seems like the DARM loop gain measured at those frequencies are too low.
I will retry the measurement.
  1545   Tue May 5 08:26:56 2009 robUpdateLockingDC Readout and DARM response

Quote:
Tonight, I was able to switch the DARM to DC readout a couple of times.
But the lock was not as stable as the RF DARM. It lost lock when I tried to measure the DARM loop gain.

I also measured DARM response when DARM is on RF.
The attached plot shows the DARM optical gain (from the mirror displacement to the PD output).
The magnitude is in an arbitrary unit.

I measured a transfer function from DARM excitation to the DARM error signal. Then I corrected it for the DARM open loop gain and the pendulum response to get the plot below.

There is an RSE peak at 4kHz as expected. The origin of the small bump and dip around 2.5kHz and 1.5kHz are unknown.
I will consult with the Optickle model.
I don't know why the optical gain decreases below 50Hz (I don't think it actually decreases).
Seems like the DARM loop gain measured at those frequencies are too low.
I will retry the measurement.


The optical gain does decrease below ~50Hz--that's the optical spring in action. The squiggles are funny. Last time we did this we measured the single arm TFs to compensate for any tough-to-model squiggles in the transfer functions which might arise from electronics or the suspensions.
  15572   Tue Sep 15 17:04:43 2020 gautamUpdateElectronicsDC adaptors delivered

These were delivered to the 40m today and are on Rana's desk

Quote:

I'll order a couple of these (5 ordered for delivery on Wednesday) in case there's a hot demand for the jack / plug combo that this one has. 

  14776   Fri Jul 19 12:50:10 2019 gautamUpdateSUSDC bias actuation options for SOS

Rana and I talked about some (genius) options for the large range DC bias actuation on the SOS, which do not require us to supply high-voltage to the OSEMs from outside the vacuum.

What we came up with (these are pretty vague ideas at the moment):

  1. Some kind of thermal actuation.
  2. Some kind of electrical actuation where we supply normal (+/- 10 V) from outside the vacuum, and some mechanism inside the chamber integrates (and hence also low-pass filters) the applied voltage to provide a large DC force without injecting a ton of sensor noise.
  3. Use the blue piers as a DC actuator to correct for the pitch imbalance --- Kruthi and Milind are going to do some experiments to investigate this possibility later today.

For the thermal option, I remembered that (exactly a year ago to the day!) when we were doing cavity mode scans, once the heaters were turned on, I needed to apply significant correction to the DC bias voltage to bring the cavity alignment back to normal. The mechanism of this wasn't exactly clear to me - furthermore, we don't have a FLIRcam picture of where the heater radiation patter was centered prior to my re-centering of it on the optic earlier this year, so we don't know what exactly we were heating. Nevertheless, I decided to look at the trend data from that night's work - see Attachment #1. This is a minute trend of some ETMY channels from 0000 UTC on 18 July 2018, for 24 hours. Some remarks:

  1. We did multiple trials that night, both with the elliptical reflector and the cylindrical setup that Annalisa and Terra implemented. I think the most relevant part of this data is starting at 1500 UTC (i.e. ~8am PDT, which is around when we closed shop and went home). So that's when the heaters were turned off, and the subsequent drift of PIT/YAW are, I claim, due to whatever thermal transients were at play.
  2. Just prior to that time, we were running the heater at close to its maximum rated current - so this relaxation is indicative of the range we can get out of this method of actuation.
  3. I had wrongly claimed in my discussion with Rana this morning that the change in alignment was mostly in pitch - in fact, the data suggests the change is almost equal in the two DoFs. Oplev and OSEMs report different changes though, by almost a factor of 2....
  4. The timescale of the relaxation is ~20 minutes - what part(s) of the suspension take this timescale to heat up/cool down? Unlikely to be the wire/any metal parts because the thermal conductivity is high? 
  5. In the optimistic scenario, let's say we get 100 urad of actuation range - over 40m, this corresponds to a beam spot motion of ~8mm, which isn't a whole lot. Since the mechanism of what is causing this misalignment is unclear, we may end up with significantly less actuation range as well.
  6. I will repeat the test (i.e. drive the heater and look for drift in the suspension alignment using OSEMs/Oplev) in the afternoon - now I claim the radation pattern is better centered on the optic so maybe we will have a better understanding of what mechanisms are at play.

Also see this elog by Terra.

Attachment #2 shows the results from today's heating. I did 4 steps, which are obvious in the data - I=0.6A, I=0.76A, I=0.9A, and I=1.05A.


In science, one usually tries to implement some kind of interpretation. so as to translate the natural world into meaning.

  12708   Thu Jan 12 17:31:51 2017 gautamUpdateCDSDC errors

The IFO is more or less back to an operational state. Some details:

  1. The IMC mirror excess motion alluded to in the previous elog was due to some timing issues on c1sus. The "DAC" and "DK" blocks in the c1x02 diag word were red instead of green. Restarting all the models on c1sus fixed the problem
  2. When c1ioo was restarted, all of Koji's changes (digital) to the MC WFS servo where lost as they were not committed to the SDF. Eric suggested that I could just restore them from burt snapshots, which is what I did. I used the c1iooepics.snap file from 12:19PM PST on 26 December 2016, which was a time when the WFS servo was working well as per this elog by Koji. I have also committed all the changes to the SDF. IMC alignment has been stable for the last 4 hours.
  3. Johannes aligned and locked the arms today. There was a large DC offset on POX11, which was zeroed out by closing the PSL shutter and running LSC offsets. Both arms lock and stay aligned now.
  4. The doubling oven controller at the Y end was switched off. Johannes turned it on.
  5. Eric and I started a data consistency check on the RAID array yesterday, it has completed today and indicated no issues
  6. NDS2 is now running again on megatron so channel access from outside should(???) be possible again.

One error persists - the "DC" indicator (data concentrator?) on the CDS medm screen for the various models spontaneously go red and return to green often. Is this a known issue with an easy fix?

  12715   Fri Jan 13 21:41:23 2017 KojiUpdateCDSDC errors

I think I fixed the DC error issue

1. I added the leap second (leapsecond ?) entry for 2016/12/31, 23:60:00 UTC to daqdrc


[OLD]
set gps_leaps = 820108813 914803214 1119744016;
[NEW]
set gps_leaps = 820108813 914803214 1119744016 1167264018;

2. Restarted FB and all realtime models

Now I don't see any RED light.

  15735   Tue Dec 15 12:38:41 2020 gautamUpdateElectronicsDC power strip

I installed a DC power strip (24 V variant, 12 outlets available) on the NW upright of the 1X1 rack. This is for the AS WFS. Seems to work, all outlets get +/- 24 V DC.

The FSS_RMTEMP channel is very noisy after this work. I'll look into it, but probably some Acromag grounding issue.

In the afternoon, Jordan and I also laid out 4x SMA LMR240 cables and 1x DB15 M/F cable from 1X2 to the NE corner of the AP table via the overhead cable trays.

  15699   Thu Dec 3 10:46:39 2020 gautamUpdateElectronicsDC power strip requirements

Since we will have several new 1U / 2U aLIGO style electronics chassis installed in the racks, it is desirable to have a more compact power distribution solution than the fusable terminal blocks we use currently. 

  • The power strips come in 2 varieties, 18 V and 24 V. The difference is in the Dsub connector that is used - the 18 V variant has 3 pins / 3 sockets, while the 24V version uses a hybrid of 2 pins / 1 socket (and the mirror on the mating connector).
  • Each strip can accommodate 24 individual chassis. It is unlikely that we will have >24 chassis in any collection of racks, so per area (e.g. EX/EY/IOO/SUS), one each of the 18V and 24V strips should be sufficient. We can even migrate our Acromag chassis to be powered via these strips.
  • Details about the power strip may be found here.

I did a quick walkaround of the lab and the electronics rack today. I estimate that we will need 5 units of the 24 V and 5 units of the 18 V power strips. Each end will need 1 each of 18 V and 24 V strips. The 1Y1/1Y2/1Y3 (LSC/OMC/BHD sus) area will be served by 1 each 18 V and 24 V. The 1X1/1X2 (IOO) area will be served by 1 each 18 V and 24 V. The 1X5/1X6 (SUS Shadow sensor / Coil driver) area will be served by 1 each of 18 V and 24 V.  So I think we should get 7 pcs of each to have 2 spares.

Most of the chassis which will be installed in large numbers (AA, AI, whitening) supports 24V DC input. A few units, like the WFS interface head, OMC driver, OMC QPD interface, require 18V. It is not so clear what the input voltage for the Satellite box and Coil Drivers should be. For the former, an unregulated tap-off of the supply voltage is used to power the LT1021 reference and a transistor that is used to generate the LED drive current for the OSEMs. For the latter, the OPA544 high current opamp used to drive the coil current has its supply rails powered by again, an unregulated tap-off of the supply voltage. Doesn't seem like a great idea to drive any ICs with the unregulated switching supply voltage from a noise point of view, particularly given the recent experience with the HV coil driver testing and the PSRR, but I think it's a bit late in the game to do anything about this. The datasheet specs ~50 dB of PSRR on the negative rail, but we have a couple of decoupling caps close to the IC and this IC is itself in a feedback loop with the low noise AD8671 IC so maybe this won't be much of an issue.

For the purposes of this discussion, I think both Satellite Amp and Coil Driver chassis can be driven with +/- 24 V DC.


On a side note - after the upgrade will the "Satellite Amplifiers" be in the racks, and not close to the flange as they currently are? Or are we gonna have some mini racks next to the chambers? Not sure what the config is at the sites, and if the circuits are designed to drive long cables.

  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

 

  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

 

  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.

 

  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).

 

 

  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

  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.

  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.

  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). 

  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. 

  17131   Fri Sep 2 15:40:25 2022 AnchalSummaryALSDFD cable measurements

[Anchal, Yehonathan]

I laid down another temporary cable from Xend to 1Y2 (LSC rack) for also measuring the Q output of the DFD box. Then to get a quick measurement of these long cable delays, we used Moku:GO in oscillator mode, sent 100 ns pulses at a 100 kHz rate from one end, and measured the difference between reflected pulses to get an estimate of time delay. The other end of long cables was shorted and left open for 2 sets of measurements.

I-Mon Cable delay: (955+/- 6) ns / 2 = 477 +/- 3 ns

Q-Mon Cable delay: (535 +/- 6) ns / 2 = 267 +/- 3 ns

Note: We were underestimating the delay in I-Mon cable by about a factor of 2.

I also took the opportunity to take a delay time measurement of DFD delayline. Since both ends of cable were present locally, it made more sense to simply take a transfer function to get a clean delay measurement. This measurement resulted with value of 197.7 +/- 0.1 ns. See attached plot. Data and analysis here.

  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?).

  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.
  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.

  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.

  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)

  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.

  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.
ELOG V3.1.3-