40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 215 of 341  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  9433   Mon Dec 2 16:04:47 2013 JamieUpdateCDSc1iscex timing problem mysteriously disappears??? (thanksgiving miracle???)

Quote:

There is definitely a timing distribution malfunction at the c1iscex IO chassis.  There is no timing link between the "Master Timer Sequencer D050239" at the 1X6 and the c1iscex IO chassis.  Link lights at both ends are dead.  No timing, no running models.

It does not appear to be a problem with the Master Timer Sequencer.  I moved the c1iscey link to the J15 port on the sequencer and it worked fine.  This means its either a problem with the fiber or the timing card in the IO chassis.  The IO timing card is powered and does have what appear to be normal status lights on (except for the fiber link lights).  It's getting what I think is the nominal 4V power.  The connection to the IO chassis backplane board look ok.  So maybe it's just a dead fiber issue?

I do not know what could have been the problem with c1auxex, or if it's related to the fast timing issue.

I just got over here from Downs, where I managed to convince Todd to let me borrow one of their three remaining timing slave boards for c1iscex.  I walked down to the X end to replace the board only to discover that the link light on the existing timing board was back!  c1iscex was not responding, so I hard rebooted the machine, and everything came up rosy (all green!):

festatus.png

To repeat, I DID NOTHING.  The thing was working when I got here.  I have no idea when it came back, or how, but it's at least working for the moment.  I re-enabled the watchdog for ETMX SUS and it's now damped normally.

I'm going to hold on to the timing card for a couple of days, in case the failure comes back, but we'll need to return it to Downs soon, and probably think about getting some spare backups from Columbia.

  9434   Mon Dec 2 17:05:13 2013 JenneUpdateCDSc1iscex timing problem mysteriously disappears??? (thanksgiving miracle???)

Steve was trying to do something to it this morning, but I'm not exactly clear on what it was.  Maybe that helped?  Steve, can you tell us what you were trying to do this morning?

  9435   Tue Dec 3 07:42:23 2013 SteveUpdateCDSc1iscex timing problem mysteriously disappears??? (thanksgiving miracle???)

Quote:

Steve was trying to do something to it this morning, but I'm not exactly clear on what it was.  Maybe that helped?  Steve, can you tell us what you were trying to do this morning?

 I was trying to repeat  elog 9007  I did only get to line 2 of the Solution by Koji when Ottavia shut down, where I was working. This was all what I did.

  9436   Tue Dec 3 17:08:06 2013 KojiUpdateCDScomputer problems

It seems that the front fan unit was running at the full speed. The fan itself seems still OK.

I talked with Jamie and make a power cycling (i.e. shutdown gracefully, unplug the power supply cables (x4), plug them in again, and pushed the power button)

The warning signal went off and the fan is quiet. FOR NOW.

Now, daqd and ndsd is down.

FB cannot mount /opt/rtcds and /cvs/cds during its boot.

After mounting these manually, I tried to run /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab
but they don't keep running.

I'll be back to this issue tomorrow with Jamie's help.

  9437   Wed Dec 4 12:02:39 2013 KojiUpdateCDSFB restored

Now FB is fixed: daqd and nds are running


When I rebooted FB, I noticed that any of the nfs file systems were not mounted.
I started tracking down the issues from here.

I googled the common issues of the nfs mounting during the boot sequence.
- It is good to give "_netdev" option to fstab to mount the system after the network connection is established.

- "auto" option specifies that the file system is mounted when mount -a is run

Resulting /etc/fstab is this:

/dev/sdb1                            /            ext3    noatime                    0 1
/swapfile                            none         swap    sw                         0 0
shm                                  /dev/shm     tmpfs   nodev,nosuid,noexec        0 0
/dev/sda1                            /frames      ext3    noatime                    0 0
linux1:/home/cds/                    /cvs/cds     nfs     _netdev,auto,rw,bg,soft    0 0
linux1:/home/cds/rtcds               /opt/rtcds   nfs     _netdev,auto,rw,bg,soft    0 0
linux1:/home/cds/rtapps              /opt/rtapps  nfs     _netdev,auto,rw,bg,soft    0 0
linux1:/home/cds/caltech/apps/linux  /opt/apps    nfs     _netdev,auto,rw,bg,soft    0 0

But this didn't help mounting the nfs file systems at boot yet. I dug into google again and found a command "/sbin/rc-update".
"/sbin/rc-update show" shows what services are activated at boot. It did not include "nfsmount". So the following command
was executed

 

> sudo /sbin/rc-update add nfsmount boot

> /sbin/rc-update show

* Broken runlevel entry: /etc/runlevels/boot/portmap
            bootmisc | boot                         
             checkfs | boot                         
           checkroot | boot                         
               clock | boot                         
         consolefont | boot                         
               dcron |      default                 
               dhcpd |      default                 
            hostname | boot                         
            in.tftpd | boot                         
             keymaps | boot                         
               local |      default nonetwork       
          localmount | boot                         
             modules | boot                         
               monit |      default                 
                  mx |      default                 
            net.eth0 |      default                 
              net.lo | boot                         
            netmount |      default                 
                 nfs | boot                         
            nfsmount | boot                         
          ntp-client | boot default                 
           rmnologin | boot                         
           rpc.statd | boot                         
                sshd | boot                         
           syslog-ng | boot                         
      udev-postmount |      default                 
             urandom | boot                         
              xinetd |      default

After rebooting, I confirmed that the nfs file systems are correctly mounted
and daqd and nds are automatically started.

This means that FB had never been configured to run correctly at boot. Shame on you!

  9438   Wed Dec 4 13:37:34 2013 JenneUpdateCDSc1auxex down again

Quote:

1) c1auxex - fixed

Tried telnet c1auxex => rejected by the host

Went down to the south end. Power cycled the target. Came back to the control room.
=> Confirmed the epics read/write is back.
Burtrestored the epics vars for the target to the snapshot on 31th Oct at 5:07.

 When I came in this morning, in addition to the fb being unhappy [elog 9436] (which Koji later fixed [elog 9437] ), c1auxex was down / not talking to the world nicely. 

I tried telnet-ing, but was rejected, so EricQ and I went down to the Xend and pushed the reset button on the computer.  The computer came back up just fine, and I did a burt restore to 03:07 on Nov 30th.

  9439   Wed Dec 4 14:16:42 2013 JenneUpdateLSCPRFPMI flashes on transmission QPDs

2 weeks ago I took some data, and remembered today at the 40m meeting that I hadn't posted it.  Bad grad student.

All I'm trying to show here is that we see flashes in the arms that are larger than the ~50 units that we see saturate the Thorlabs transmission PDs. For arm power values below ~50, the QPD sum and Thorlabs PDs give approximately the same values.  So, 1 unit on the Thorlabs PDs is equivalent to 1 unit on the QPD sum, and 50 units on the Thorlabs diode is equivalent to 50 units on the QPD sum.

The situation was arms held on resonance with ALS, and the PRMI was flashing.

ArmsResonatingUsingALS_PRMIflashing_TRX_TRY.pdf

Arm powers of ~140 imply a power recycling gain of ~7.

  9441   Wed Dec 4 21:33:24 2013 KojiUpdateCDSc1scy time-over issue mitigated

c1scy had frequent time-over. This caused the glitches of the OSEM damping servos.

Today Eric Q was annoyed by the glitches while he worked on the green PDH inspection at the Y-end.

In order to mitigate this issue, low priority RFM channels are moved from c1scy to c1tst.
The moved channels (see Attachment 1) are supposed to be less susceptible to the additional delay.

This modification required the following models to be modified, recompiled, reinstalled, and restarted
in the listed order:
c1als, c1sus, c1rfn, c1tst, c1scy

Now the models are are running. CDS status is all green.
The time consumption of c1scy is now ~30us (porevious ~60us)
(see Attachment 2)

I am looking at the cavity lock of TEM00 and I have witnessed no glitch any more.
In fact, the OSEM signals have no glitch. (see Attachment 3)

We still have c1mcs having regularly time-over. Can I remove the WFS->OAF connections temporarily?

Attachment 1: TST.png
TST.png
Attachment 2: CDS.png
CDS.png
Attachment 3: no_glitch.png
no_glitch.png
  9442   Wed Dec 4 21:41:09 2013 ericqUpdateGreen LockingGreen PDH Characterization

 My job right now is to characterize the green PDH loops on each arm. Today, Jenne took me around and pointed at the optics and electronics involved. She then showed me how to lock the green beams to the arms (i.e. opening the shutters until you hit a TM00 shape on the transmitted beam camera). Before lunch, the y arm was easiest to lock, and the transmitted power registered at around 0.75. 

After lunch, I took a laptop and SR785 down to the y end station. I unhooked the PDH electronics and took a TF of the servo (without its boost engaged, which is how it is currently running) and noise spectrum with the servo input terminated.

I then set up things a la ELOG 8817 to try and measure the OLTF. However, at this point, getting the beam to lock on a TM00 (or something that looked like it) was kind of tough. Also, the transmitted power was quite a bit less than earlier (~0.35ish), and some higher order modes were higher than that (~0.5). Then, when I would turn on the SR785 excitation, lock would be lost shortly into the measurement, and the data that was collected looked like nonsense. Later, Koji noted that intermittent model timeouts were moving the suspensions, thus breaking the lock. 

We then tried to lock the x arm green, to little success. Koji came to the conclusion that the green input pointing was not very good, as the TM00 would flash much less brightly than some of the much higher order modes. 

Tomorrow, I will measure the x arm OLTF, as it doesn't face the same timeout issue that is affecting the y arm.

  9443   Thu Dec 5 11:06:43 2013 SteveUpdateCameras viewport video ccd cameras are all covered

Quote:

Quote:

Can't we somehow hook up this camera to the MUX with the movie mode?
I think both the MUX and the sensoray are compatible with the color video signal.
Only the old CRT is B/W.

 Watek 902H ccd with Tamron M118FM50 lens is hooked up to MUX  Please be careful! In this set up the lens is close to the view port glass window! 

 PRM-BS & Faraday video ccd  cameras  covered as shown. These thin wall metalized ducts are perfect for blocking light in both direction.

They are very light and give you easy access to adjustment.

Attachment 1: PRMcamera.jpg
PRMcamera.jpg
Attachment 2: PRMcameraCover.jpg
PRMcameraCover.jpg
Attachment 3: FaradayCameraCover.jpg
FaradayCameraCover.jpg
  9444   Thu Dec 5 12:20:09 2013 JenneUpdateCDSfixing c1mcs timing - go for it

Quote:

We still have c1mcs having regularly time-over. Can I remove the WFS->OAF connections temporarily?

 Yes.  I think that's a good idea, since we're not using them at this time, and we want c1mcs to behave.  Maybe make an elog note of which version is the first without them, so that we can conveniently find the model(s) in the svn?

  9445   Thu Dec 5 16:20:26 2013 SteveUpdateCDSglitches are gone

Quote:

c1scy had frequent time-over. This caused the glitches of the OSEM damping servos.

Today Eric Q was annoyed by the glitches while he worked on the green PDH inspection at the Y-end.

In order to mitigate this issue, low priority RFM channels are moved from c1scy to c1tst.
The moved channels (see Attachment 1) are supposed to be less susceptible to the additional delay.

This modification required the following models to be modified, recompiled, reinstalled, and restarted
in the listed order:
c1als, c1sus, c1rfn, c1tst, c1scy

Now the models are are running. CDS status is all green.
The time consumption of c1scy is now ~30us (porevious ~60us)
(see Attachment 2)

I am looking at the cavity lock of TEM00 and I have witnessed no glitch any more.
In fact, the OSEM signals have no glitch. (see Attachment 3)

We still have c1mcs having regularly time-over. Can I remove the WFS->OAF connections temporarily?

 Koji cleaned up very nicely.

Attachment 1: glitchesGONE.png
glitchesGONE.png
Attachment 2: NOglitches.png
NOglitches.png
  9446   Fri Dec 6 10:03:07 2013 SteveUpdateSUSIR effect on MC sensors only

Quote:

 Sorry to say but MC1, MC2, MC3 and PRM face OSEMS are having the same problem of leaking IR into the sensors

The PMC was not locked for 11 minutes on this plot.

 

 The PRM sensors are no longer effected by IR. What changed? The MC still does.

Attachment 1: 10minPMCnotLocked.png
10minPMCnotLocked.png
Attachment 2: 6Dec2013.png
6Dec2013.png
  9447   Fri Dec 6 12:45:51 2013 ericqUpdateGreen LockingGreen PDH Characterization

Yesterday, made a slew of measurements on the X-arm when locked on green. By tweaking the temperature loop offset and the green input PZT pointing, I was able to get the transmitted green to around 1.0. The PDH board gain was set to 4.0. I had trouble making swept sine measurements of the OLTF; changing the excitation amplitude for different frequency ranges would result in discontinuities in the measured TF, and there was only a pretty narrow band around the UGF that seemed to have reasonable coherence.

So, I used the SR785 as a broadband noise generator and measured the TF via dividing the spectra in regions of coherence. Specifically, I used the "pink noise" option of the SR785. I also used a SR560 as a low pass to get enough noise injected into the lower frequency range to be coherent, while not injecting so much into the higher frequencies that the mode hopped while measuring. 

The servo board TF was easily fitted to a 4th order zpk model via VFIT, but I'm having trouble fitting the OLTF. (There is a feature in the servo TF that I didn't fit. This is a feature that Zach saw [ELOG 9537], and attributed to op amp instability) Plots follow. Also, while these need to be calibrated to show the real noise spectrum of the cavity motion, I'm attaching the voltage noise spectra of the error and control signals as a check that electronics/PD noise isn't dominating either signal. 

LoopTF.pdfServoTF.pdf

MixerOutput.pdfServoOutput.pdf

  9448   Fri Dec 6 15:57:41 2013 SteveUpdateIOObeam dumps for PSL pointing monitoring

Quote:

Since the pointing has gone bad again, I went to the PSL to investigate. Found some bad things and removed them:

1) There was a stopped down iris AGAIN in the main beam path, after the newly installed mirror mount. I opened it. Stop closing irises in the beam path.

2) The beam dump for the IOO QPD reflection was just some black aluminum. That is not a real dump. I removed it. We need two razor blade dumps for this.

3) There was an ND filter wheel (???) after one of the PMC steering mirrors. This is not good noise / optics practice. I removed it and dumped the beam in a real dump. No elog about this ?!#?

 

The attached trend shows the last 20 days. The big step ~2 weeks ago is when Steve replaced the steering mirror mount with the steel one. I don't understand the drift that comes after that.

 

Today I also spent ~1 hour repairing the Aldabella laptop. Whoever moved it from the PSL area to the SP table seems to have corrupted the disk by improper shutdown. Please stop shutting the lid and disconnecting it from the AC power unless you want to be fixing it. Its now running in some recovery mode. Lets leave it where it is next to the PSL and MC1.

I steered the MC suspensions back to where they were on the trends before the PSL mirror mount swap and then aligned the PSL beam into it by touching the last 2 steel mounts. Once the alignment was good without WFS, I centered the beams on the IOO QPDs. If it behaves good overnight, I will center the unlocked beams on the MC WFS.

 

Please stay off the PSL for a couple days if you can so that we can watch the drift. This means no opening the doors, turning on the lights, or heavy work around there.

 IOO pointing monitoring qpds received razor beam dumps on their refs.

The Pos QPD was rotated and recentered.

The Ang QPD was left untouched.

TREND plot of 23 days is attached.

Attachment 1: IOO_QPD_MONS.jpg
IOO_QPD_MONS.jpg
Attachment 2: PointingTrend23d.png
PointingTrend23d.png
  9449   Fri Dec 6 21:38:27 2013 KojiUpdateLSCCDS related activities for LSC

I worked on the CDS related stuffs for LSC yesterday and today.


1. Slow machines:

I checked the database files for c1iscaux and c1iscaux2 (slow machines). They are mainly
used for the control of LSC whitening filters. The channel names were totally random as we
reconfigured the RF PDs while the channel names had been unchanged.

- Now the database was modified so that the PD name and the channels are related.
- saverestore.req and autoBurt.req were also changed accordingly.

- PD interface channels are completely random. Don't use them.
- I found the whitening of DCPDs are not effective.

- We need to clean up /cvs/cds/caltech/target directory. The autoBurt requests in the old targets
are making unnecessary burt files.

2. LSC screens

- The channel names on the LSC OVERVIEW screen was modified. (Attachment 1)
- A new LSC Whitening screen was made. (Attachment 2)

3. LSC screen generator

To touch the main LSC screen is very tough. The screen was split in to several sub screens
and combined with a command.

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/generateLSCscreen.py

This command combines the multiple adl files into a single file with x&y offsets.
This way, you can work with the each section of the screen.
Also, moving the blocks are just easy.

4. LSC Code Bug?

During the screen making, I found that a couple of the whitening switches are not
working properly.
e.g. When AS165 (either I or Q) FM1 is activated throught the whitening trigger,
the MSB bit (bit15) of the binary I/O (C1:LSC-BIO_0_0) does not .

SImilarly ASDC FM1 does not toggle bit15 of C1:LSC-BIO_0_1.

The other channels seems OK.

At first, I thought this is a bug of "Bit2Word" block. But an individual test of the block showed that
the block is not guilty. So why is only Bit15 malfunctioning???

 

Attachment 1: LSC1.png
LSC1.png
Attachment 2: LSC2.png
LSC2.png
  9450   Sat Dec 7 19:29:14 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

In order to unify the theme for MEDM screens, I'll have to make many combinations of rectangles, polygons, and invisible related-screen buttons.
Everytime I change the size of the block, I have to modify the size of this combination. It is impossile for me.

So, I made a script to replace a certain type of rectangles with a combination of the objects with the same (or related) size.

The script is here (so far)

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

So far, there is only "TYPE1" for the predefinition. It actually takes another argument to specify the
path of the related screen to open when the block is clicked. The path should be filled in "Channel B"
slot of the original rectangle. (See Attachment 1)

The "TYPE1" style has the function calls as indicated below. place_rect is to place a rectangle object. You can
specify the filling method and color. place_rel_disp is to place an invisible button with the link to the specified
path by strOpt. place_polygon places a polygon. The cordinate array for the polygon is described with
the relative positions from the specified position.

        place_rect(rect_x-4,         rect_y-4,        rect_w+7, rect_h+7, "outline",  0) # outline white box
        place_rel_disp(rect_x, rect_y, rect_w, rect_h, strOpt, 0, 14)                    # invisible button
        place_rect(rect_x,           rect_y,          rect_w,   rect_h,   "fill",     3) # main gray box
        place_rect(rect_x+3,         rect_y,          rect_w-6, 3,        "fill",     0) # top white rim
        place_rect(rect_x,           rect_y,          3,        rect_h-3, "fill",     0) # left white rim
        place_rect(rect_x+rect_w-3 , rect_y,          3,        rect_h,   "fill",    10) # right gray rim
        place_rect(rect_x,           rect_y+rect_h-3, rect_w-3, 3,        "fill",    10) # bottom gray rim
        place_polygon(rect_x+rect_w-3,rect_y,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # top-right white triangle
        place_polygon(rect_x,rect_y+rect_h-3,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # bottom-left white triangle

Attachment 1: rectangle_config.png
rectangle_config.png
Attachment 2: rect_replace_result.png
rect_replace_result.png
  9451   Mon Dec 9 11:44:08 2013 SteveUpdateendtable upgradeETMY optable got new beam dump

Aluminum shield replaced by razor beam dump.

Attachment 1: ETMYoptBefore.jpg
ETMYoptBefore.jpg
Attachment 2: ETMYoptAfter.jpg
ETMYoptAfter.jpg
  9452   Tue Dec 10 10:07:01 2013 SteveUpdateIOOmore beam traps

 New razor beam dump installed to trap reflected beam of the input vacuum window.

 

Attachment 1: InputWindowRefDump.jpg
InputWindowRefDump.jpg
Attachment 2: InpWindowRefDupm.jpg
InpWindowRefDupm.jpg
  9453   Tue Dec 10 15:13:55 2013 KojiUpdateIOOIMC servo inspection

Yesterday evening I inspected at IMC servo as a preparation of the CM servo recommissioning.

More details to come.

  9454   Tue Dec 10 17:27:47 2013 JenneUpdateTreasureBaby oplev LQR designed loop

I *finally* figured out how to bend Matlab to my will, and close a very simple oplev loop using LQR technology. 

This is super, super simple, but it's a step in the right direction.  There is no noise, just a simple pendulum with a resonant frequency of 0.75Hz, and a Q of 10.  The LQR tries to keep the position of the pendulum at a minimum, and does not care at all about the velocity.  You cannot (with Matlab's LQR, at least that I can find) make it care "0" about the control output, so it cares about the control output a factor of 1e-4 as much as the position.

Here are some plots:

The first plot has the open loop system (just the pendulum, no control at all), as well as the closed loop system (the pendulum under control).

NoControlVsClosedLoop_BabyOplev.png

Plot 2 is the open loop gain of the controller that the LQR designed.

OpenLoopGain_BabyOplev.png

Plots 3 and 4 are the step and impulse responses of the open loop (pendulum with no control), and closed loop (pendulum with feedback) systems.

StepResp_BabyOplev.png

ImpResp_BabyOplev.png

The conclusion from the plots (if this were an interesting system) is that it doesn't take much to damp an ideal pendulum.  The real conclusion here is that I think I now know how to use the Matlab LQR function, and can make a loop with some noise now.

  9455   Thu Dec 12 00:21:04 2013 KojiUpdateGreen LockingX end PDH box oscillation issue solved (Re: screwed up the end PDH box)

What a such long pain we suffered.

After more than three years from Kiwamu's discovery, the PDH box 50kHz oscillation issue was finally solved.

This "weird peak at 50kHz" was caused by the oscillation of the voltage regulator (ON's MC7912).
As it imposed common noise almost everywhere, it screwed up transfer function measurements
like EricQ saw recently.

The negative voltage regulator (79XX) tends to get unstable than the positive counter parts (78XX).

The oscillation was removed by adding 22uF electrolytic capacitor between the output pin (pin3) and the ground pin (pin1) of MC7912.
This is indeed more than 20 times of the specification you can find in the data sheet.

  9456   Thu Dec 12 00:47:45 2013 DenUpdateLSClocking activity

Jenne, Den

Today we worked on PRM angular servos and Y-arm ALS stabilization.

In the current PRMI angular control configuration two servos simultaneously drive PRM - oplev and POP ASC. We considered 2 ways to redesign this topology:

  • once lock is acquired, turn on POP ASC servo that corrects oplev error signal
  • turn off PRM oplev and turn on POP ASC  servo

The first option requires model rewiring so we started from the second one. We had to redesign POP ASC pitch and yaw servos for this because PRM TF has changed. Attached is servo OLTF.

This method worked out well and once PRMI is locked we turned off oplev servo with ramp of 0.5 sec and enable ASC POP servo with ramp of 1 sec.

Once PRMI was locked and ASC running we have turned off PRM angular local damping that presumably prevents us from bringing arms into resonance due to IR coupling to shadow sensors.

PRMI was stable using only ASC POP servo and we moved on to ALS. We found Y-arm beatnote and enabled control to ETMY.

Cavity was stabilized but not robust - we were loosing IR in a minute because green relocked to 01 mode with transmission equal to more than half of 00 mode. This is probably due to angle to length coupling of ETMY.

We were also loosing IMC during cavity stabilization. We made MCL servo and will tune it tomorrow looking at the arm spectrum as an OOL sensor.

Attachment 1: POP_ASC.pdf
POP_ASC.pdf
  9457   Thu Dec 12 14:57:01 2013 KojiUpdateIOOIMC servo inspection

In order to accomplish CARM control with the PSL laser frequency, we use two actuators.

One is the longitudinal direction of one of the MC mirrors. The londitudinal motion of the MC induces
the laser frequency control via the MC servo. As we move the mirror, the range is sort of big,
but the BW is limited by the mechanical response.

The other is the additive offset path. We inject a signal to the additional input port of the MC.
The MC servo supresses this injection by giving the same amount but oppsite sign offset to
the error signal (before the addtion of the inputs). The bandwidth of this AO path is limited
by the bandwidth of the MC servo. Basically the BW of the AO path is about 1/10 of that of the MC servo.

In order to confirm the capability of the AO path as a frequency actuator, 1) OLTF of the MC servo
2) TF of the AO input to the servo error was measured.

Attachment 1 shows the openloop TF of the MC servo. The UGF seems just little bit higher than
100kHz. The OLTF is empirically modelled by LISO as seen in the figure.

Attachment 2 shows the TF from the additive input (In2) to the error monitor (MC Servo module Q error mon).
The gain setting of the MC servo box was: In1 +18dB, In2 0dB. The measured TF has arbitorary gain 
due to the gain setting, the measuemrent data was multiplied by 4 to mach the DC value to the unity.
This is to compare the measurement with the prediction from the OLTF.

The AO path TF is expected to show the character of -G/(1+G) where G is the OLTF. In my case,
G = 0.75*OLTF showed the best maching. There might have been some misalignment of the MC
upon the AO path measurement as I found after the measurement.

From the plot , we can see that the response is flat up to 20kHz. Above that it rapidly raises.
This should be dealt with the CM servo filter as the bump may hit the unity gain. Since we have to use
strong roll off to avoid the bump, this will eat the phase margin at low frequency.

In the case that we don't like this bump:
This bump is caused by low phase mergin of the OLTF at 30~40kHz. If the total gain
is increased, the bump is reduced. Or, we can decrease the PZT loop gain in order to
reduce the dip at the crossover ferquency between the PZT and PC loops. In both cases,
the PC path suffers more actuation. We may need to think about the HV actuation option
for the PC (Apex PA85).

Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.

Attachment 1: OLTF_IMC.pdf
OLTF_IMC.pdf
Attachment 2: AOTF_IMC.pdf
AOTF_IMC.pdf
Attachment 3: 131209.zip
  9458   Thu Dec 12 17:22:07 2013 SteveUpdateGeneralrack power supplies checked

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

Attachment 1: 1x1ps.jpg
1x1ps.jpg
Attachment 2: 1X5ps.jpg
1X5ps.jpg
Attachment 3: 1X9ps.jpg
1X9ps.jpg
Attachment 4: 1Y1ps.jpg
1Y1ps.jpg
Attachment 5: 1Y4ps.jpg
1Y4ps.jpg
Attachment 6: AuxLSCps.jpg
AuxLSCps.jpg
Attachment 7: AuxOmcSouthRackPs.jpg
AuxOmcSouthRackPs.jpg
Attachment 8: 1Y2.jpg
1Y2.jpg
  9459   Thu Dec 12 21:23:15 2013 ericqUpdateGreen LockingBetter Xarm OLTF

With the newly repaired PDH board, I spent some time with the x arm green PDH loop. I found it SO MUCH EASIER to measure the OLTF by injecting before the servo, instead of after it. (i.e. I added a swept sine from the SR785 to the mixer output (error signal) before the servo input). This is likely because the error signal is much flatter. I used a 10mV excitation across the whole frequency range (30-100kHz). 

Here's the OLTF. I'm working on fitting it and breaking it up into its constituent TFs, then making a rudimentary noise budget. 

Dec12_Xarm_OLTF.pdf

  9460   Thu Dec 12 21:30:52 2013 JenneUpdateASCPRMI-relevant oplevs centered

The ITM oplevs were pretty close to the edge of their ranges, and none of the oplevs have been centered in a while, so I centered ITMX, ITMY, BS, PRM after having done alignment (arms, then PRMI).

  9461   Thu Dec 12 22:12:17 2013 KojiUpdateGreen LockingBetter Xarm OLTF

OK, the next question will be "why the loop bandwidth is so miserable?"
In other words, what is preventing us to have the bandwidth of 20~30kHz?
Your breaking down will give us the answer.

  9462   Fri Dec 13 02:19:57 2013 JenneUpdateLSClocking activity

[Jenne, Den]

Tonight we worked on tweaking up the PRCL new ASC, and then PRMI+1 arm locking.  We were unable to get the Xarm to stay locked on a TEM00 mode for very long, and after an hour or two of using the PZTs to try to align the beam to the cavity, we gave up and just used Yarm green.

NB: We haven't done anything to MCL, although it is not in use.  Den is still going to get around to elogging what servo shaping he changed on that last night.

I wrote a script that will handle the transitions between the new PRCL ASC and the PRM oplev and local damping.  The script is accessible from the PRC ASC screen, and will detect when the PRMI is locked or not.  When it is locked, it will turn down the PRM oplev gains and turn on the ASC, and then it will turn off the local shadow sensor damping for PRM pitch and yaw.  When the PRMI unlocks, the script will turn off the ASC and restore oplev and local shadow sensor damping. 

We saw that the bounce mode of the PRM was getting rung up with our new ASC, so we included a band stop in the ASC, and also turned on the triggering for the PRCL LSC FM6, which has the resonant gain for the bounce mode (as well as roll, and the stack mode).  This made the PRMI spot very stable. 

We then moved on to green arm locking.  The Yarm is behaving perfectly nicely (as nice as it has been lately - it's alignment and mode matching could also use some work), but Xarm was giving us a bit of trouble.  As always (since the PZTs were installed?), the mode matching isn't excellent for the green to the arm, so it can be hard to catch a TEM00 mode.  Also, even if we did catch a good mode, it would often not stay locked for more than a few tens of seconds.  We tried several alignment tweakings, and several different end laser temperatures (within the confines of seeing the beatnote under 100MHz), and didn't have a lot of success.  It looks like Eric had the slow servo engaged for the Xend laser, so the temperature offset was something like +300,000, which seemed totally crazy.  I turned that off, and found the beatnote somewhere around output of -10,300.  So, I haven't gone to the end to look at the temperature, but it's going to be different than when Eric was taking measurements this afternoon.  It seems like the main problem with the Xarm is poor mode matching - the maximized input pointing for TEM00, when you unlock and relock the cavity, is just as likely to give you a TEM_9_0 mode, as TEM00.

So, we gave up on the Xarm for the evening, and tried PRMI+1arm, with the new PRCL ASC.  This was successful!   The Yarm beatnote was around laser slow servo output of +4450.  Beatnote at 46.0MHz, -26dBm.  We found the IR resonance, moved off, locked the PRMI, transitioned to the new ASC, and brought the Yarm back to IR resonance.  What we see is that the power fluctuations in the PRC are much smaller than they were back around Halloween (elog 9338), however the arm power fluctuations still seem very, very large.  This is certainly partly due to the fact that we haven't done a thorough Yarm alignment since before messing with the greens, so we will have drifted somewhat.  Also, the ALS beatnote sensor isn't perfect, so won't be perfect at holding us near resonance. 

Den is thinking about whether we can use the arm transmission QPD signals to feed back to the ETM ASC servos, to try to reduce the RIN in the arms.  I feel like we should also see if this amount of power fluctuation can be explained by our ALS noise, because maybe we'll be fine once we transition to IR and turn off the ALS system.   Attached is a plot showing that the arm's RIN is coherent with the spot motion seen by the transmission QPD, so we need to check the alignment of the cavity, as well as consider using the trans QPD in an ASC feedback loop.

Here is a plot of the PRC sideband power, as well as the Yarm transmission.  The GPS time for this plot is approximately 1070963372.

PRMI_Yarm_NewPRCLasc.png

Attachment 2: try_dc.pdf
try_dc.pdf
  9463   Fri Dec 13 02:30:22 2013 KojiUpdateLSClocking activity

According to the measurement by Eric, the X-arm green PDH UGF is too low. We still have some room to increase the gain.

The out of loop stability of the ALS for each arm should be measured everyday.
Otherwise we can't tell whether the arm is prepared for advanced locking activities or not.

We expect to see the arm stablity of ~50pm_rms for the Y arm and ~150pm_rms for the X arm.

  9464   Fri Dec 13 11:47:11 2013 GabrieleUpdateGreen LockingBetter Xarm OLTF

I'm not as good as a fit, but it seems that there is a loop delay of about 30 microseconds, looking at the high frequency phase. This might explain the limitation on the BW. Eric should be able to get the delay out of the fit with some care.

  9465   Fri Dec 13 13:28:07 2013 DenUpdateLSCarm calibration template

I have calibrated ETMX and ETMY actuators and added a template armSpectra.xml into /users/Templates directory.

Template shows control and error signals of both arms. Procedure is standard: calibrate control to meters and match error based on UGF measurement. XARM UGF: 200 Hz, YARM UGF 210 Hz.

Noise level at high frequencies (>100 Hz) for YARM is 3*10-15 and is factor of 3 better then for XARM. Servo gains are in the same ratio. I think there is less light on POX than on POY RF PD because I checked phase rotation and analog gain. I assume transimpedances are the same.

Attachment 1: armsCal.pdf
armsCal.pdf
  9466   Fri Dec 13 13:45:50 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

rect_replace.py script was updated.
This sounds crazy but it was actually quite easy as I could use a free font data.


/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

Now new type "CHAR" (i.e. REPLACE_CHAR) was added. This replaces the string in Channel B slot
into 5x7 dot matrix representation of the string with the specified color. The dot size is derived from the
height of the original rectangular object.

 

Attachment 1: screen_shot.png
screen_shot.png
  9467   Fri Dec 13 16:34:20 2013 SteveUpdateVACPS will be replaced next week

Quote:

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

 The temperature went down to room temp with temporary fan in the back. Voltage and current are stable.

Regardless, it will be replaced early next week.

Attachment 1: hotPSvacRack.jpg
hotPSvacRack.jpg
Attachment 2: fan1X8.jpg
fan1X8.jpg
  9468   Fri Dec 13 18:03:00 2013 DenUpdateIOOcommon mode servo

Quote:

Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.

 It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.

Frequency response of the servo is taken from the document D040180. I assumed coupled cavity pole to be ~100 Hz.

The only question is if our EOM has enough range. Boost 2 increases noise injection by 10 dB in the frequency range 20-50 kHz. Boost 3 has even higher factor.

Attachment 1: CM_OL.pdf
CM_OL.pdf
Attachment 2: CM_CL.pdf
CM_CL.pdf
  9469   Fri Dec 13 19:33:56 2013 DenUpdateASCETM X,Y QPDs

I have modified/compiled/installed/restarted c1scx and c1scy models to include arm transmission QPDs in angular controls.

For initial test I have wired normalized QPD pitch and yaw outputs to ASC input of ETMs. This was done to keep the signals inside the model.

QPD signals are summed with ASS dither lines and control. So do not forget to turn off QPD output before turning on dither alignment.

Medm screens were made and put to medm/c1sc{x,y}/master directory. Access from sitemap is QPDs -> ETM{ X,Y} QPD

  9470   Fri Dec 13 23:07:04 2013 KojiUpdateIOOcommon mode servo

Looks good.

Once the control cable (bakplane cable) is identified, we can install the module to the LSC analog rack.

We should be able to test the CM servo with either POX or POY and only one correspoding arm without modifying the servo TF.
Just for this test, we don't need to use MCL.

  9471   Sat Dec 14 02:51:47 2013 DenUpdateLSClocking activity

I had a look on x,y arms stabilization using ALS. Input green beam was misaligned and I was loosing 00 every few minutes. I vent on the floor and realigned green beams.

YARM alignemt was smooth - transmission increased from 0.4 to 0.85 with PSL shutter off.

XARM was tough. Steering mirrors did not have any derivatives when transmission power was 0.5. I walked the beam with piezos but got only 0.55. It seems that the input beam is mismatched to the cavity. When the transmission was 1 last time? Does anyone have a model of the xend table to compute mode matching?

Input green alignent was improved and I could keep arms stabilized for periods of ~30min - 1 hour. Still not forever.

I noticed that ALS_XARM and ALS_YARM servos have limiters of 6000 and control signal had high frequency components that were not rolled off as shown on the plot "ETMY_DRIVE". I have added a low pass filter that reduced RMS by factor of 5 and took 7 degrees of phase at UGF=150 Hz. Now margin is 33 degrees.

Then I excited ETMY longitudinally at 100 Hz and measured first and second harmonics of the YARM RIN. I got total DC offset of 0.3 nm. This means significant length coupling to RIN. First of all, "scan arm" script does not tune the offset very precise. I guess it looks at DC power, checks when cavity passes through symmetrical points of the resonance and takes the average. It is also useful to look at POX/POY and confirm that average is 0. Plot "ALS_RIN" shows comparison of YARM power fluctuations when it is locked using IR and stabilized using ALS. By manually correcting the offset I could reduce length coupling into RIN, coherence was ~0.1.

Cavity RMS motion also couples length to RIN. Plot "ALS_IR" shows YARM error signal. I also looked at POY signal (LSC-YARM_IN1) as an OOL sensor. At low frequencies POY sees only IMC length fluctuations converted to frequency. I have engaged MCL path and ALS error and LSC error signals overlaped. Cavity RMS motion is measured to be 200 pm.

Attachment 1: ETMY_DRIVE.pdf
ETMY_DRIVE.pdf
Attachment 2: ALS_RIN.pdf
ALS_RIN.pdf
Attachment 3: ALS_IR.pdf
ALS_IR.pdf
  9472   Sat Dec 14 11:56:54 2013 ranaUpdateLSCcommon mode servo

Quote:

 

 It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.

 These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?

We should be able to estimate the noise coming out of the MC using the single arm and then make a guess for the CM loop gain requirement. There's no reason to keep the old Boost shapes; those were used in the old MC configuration which had a RefCav. In addition to minimizing the EOM range, we should also minimize the AO signal as Koji has pointed out. In practice, I've seen that using ~300 Hz of offset makes no harm with 4 kHz MC pole.

  9473   Sat Dec 14 13:46:54 2013 DenUpdateIOOlow bandwidth MCL loop

Last time we designed MCL loop with UGF ~ 30 Hz and I think, it was hard to lock the arm because of large frequency noise injected to IFO.

This time I made a low bandwidth MCL loop with UGF=8 Hz. MCL error RMS is suppressed by factor of 10 and arms lock fine.

Attached plots show MCL OL, MCL error suppression and frequency noise injection to arms.

It is interesting that spectrum of arms increases below 1 Hz meaning that IMC sensing noise dominates in this range.

I did not include the loop into the IMC autolocker. I think it is necessary to turn it on only during day time activity and when beatnote is moving too much during arm stabilization.

Attachment 1: MCL_OL.pdf
MCL_OL.pdf
Attachment 2: MCL_ERR.pdf
MCL_ERR.pdf
Attachment 3: MCL_ARMS.pdf
MCL_ARMS.pdf
Attachment 4: MCL_MEDM.png
MCL_MEDM.png
  9474   Sat Dec 14 14:21:46 2013 DenUpdateLSCcommon mode servo

Quote:

 

 These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?

Attached is matlab code that I used

 % IMC OL
G = zpk(-2*pi*8964, 2*pi*[-10; -10; -10; -1000; -274000], db2mag(242.5)) * ...
    tf([1 0.8*1.55e+05 3.1806e+10], 1);

% CARM PATH
CARM = G/(1+G);

% Common mode boosts
BOOST = zpk(-2*pi*4000, -2*pi*40, 1);
BOOST1 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST2 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST3 = zpk(-2*pi*4500, -2*pi*300, 1);

% Coupled cavity pole
CCPole = zpk([], -2*pi*100, 2*pi*100);

% Servo gain
Gain = db2mag(43);

% CARM OL with boosts
H = CARM * CCPole * BOOST * Gain;
H1 = H * BOOST1;
H2 = H1 * BOOST2;
H3 = H2 * BOOST3;

% Plot
% bode(H, H1, H2, H3, 2*pi*logspace(3, 5, 10000));
% bode(1/(1+H), 1/(1+H1), 1/(1+H2), 1/(1+H3), 2*pi*logspace(3, 5, 10000));

  9475   Sun Dec 15 03:13:15 2013 DenUpdateLSCattempt to reduce carm offset

X,Y arms were stabilized using ALS and moved 5 nm from the resonance, PRMI was locked on sideband using REFL165 I&Q. POP angular servo was running; PRMI RIN was good (~2-3%)

During slow offset reduction I was sweeping MICH, PRCL and POP servos for instabilities due to possible optical gain variations, loops were fine.

I could reduce offset down to ~200 pm and then lost lock due to 60 Hz oscillations as shown on the attached plot "arm_offset"

Arms were stabilized with RMS comparable to the offset and power in arms was fluctuating from 3 to 45.

60 Hz line most probably comes from MICH. RMS is dominated by the power lines and is ~ 1 nm as seen on the plot "PRMI_CAL". I think this is too much but we need to do simulations.

Attachment 1: ARM_OFFSET.pdf
ARM_OFFSET.pdf
Attachment 2: PRMI_CAL.pdf
PRMI_CAL.pdf
  9477   Sun Dec 15 21:01:19 2013 KojiUpdateLSCCM servo module installed

Now the module is inserted at the 2nd crate from the top of 1Y2 (LSC analog rack). It is next to the DCPD whitening module.

I found the backplane cable for the Common Mode servo module.
I traced a cable form XY220 at the right most module on the crate where iscaux2 is living.
This cable was connected to the upper backplane connector.

Switching of the module is tested. All the switches and gain control are doing their job.

It was found that the offset and slow readback are not responding.
I checked the schematic of the CM servo module (D040180).
It seems that there is another cable for the offset and read back voltages.

  9478   Mon Dec 16 02:20:49 2013 DenUpdateLSCMICH rms is improved

When PRMI is locked on REFL 165 I&Q signals MICH rms is dominated by the 60 Hz line and harmonics. It comes from demodulation board.

To increase SNR ZFL-100 LN amplifier (+23.5dB) was installed in LSC analog rack. MICH 60 Hz and harmonics are improved as shown on the plot "mich_err"

I have also added a few resg at low frequencies. MICH rms is not 3*10-10. In Optickle I simulated power dependence in PRC and ARMs on MICH motion. Plot is attached.

 I think we need to stabilize MICH even more, down to ~3*10-11 . We can think about increasing RF amplifier gain, modulation index and power on BB PD.

CARM offset reduction was a little better today due to improved MICH RMS. Power in arms increases up to 15 and than starts to oscillate up to 70 and then PRMI looses lock.

Tomorrow we need to discuss where to put RF amplifier. Current design has several drawbacks:

  • DC power for the amplifier is wired from a custom (not rack based) +15V power supply that was already inside the lsc rack and used for other ZFL-100LN
  • BNC cables are used because I could not find any long SMA cables
  • we would like gain of ~40 dB instead of 23.5 dB
Attachment 1: MICH_ERR.pdf
MICH_ERR.pdf
Attachment 2: DC_power.pdf
DC_power.pdf
Attachment 3: ARM_OFFSET.pdf
ARM_OFFSET.pdf
  9479   Mon Dec 16 20:08:43 2013 KojiUpdateLSCCM servo module installed

I found another backplane cable for the CM servo module. It is plugged to the module now.

I can see that C1:LSC-CM_SLOW_MON is responding to C1:LSC-CM_REFL_OFFSET.
But C1:LSC-CM_SUM_MON and C1:LSC-CM_FAST_MON are not replated to the given offset.
I probably need to check the cross connects.

  9480   Tue Dec 17 02:10:29 2013 DenUpdateLSClocking activity

Koji, Den

Some results and conclusions from tonight:

PRC macroscopic length is detuned. We measured REFL phases in carrier and sideband configurations - they are different by ~45 degrees for both 11 and 55 MHz sidebands. Additional measurement with phase locked lasers is required.

We got stable lock of PRMI+2arms with CARM offset of ~200 pm. We think this is the point when we should transition to 1/sqrt(TR) signals. We plan to rewire LSC model and also test CM servo with 1 arm during the day.

POP ASC OL shape changes when we reduce CARM offset probably due to normalization by sum inside the PD. Servo gets almost useless when PRMI power fluctuates by a factor of few.

SMA cables were made and installed for the REFL165 RF amplifier in lsc rack.

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

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

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

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

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

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

Attachment 1: POP22110sch.pdf
POP22110sch.pdf
Attachment 2: POP22110.pdf
POP22110.pdf POP22110.pdf
  9482   Tue Dec 17 20:59:23 2013 JenneUpdateLSC1/sqrt(TR) signals added to frames

I noticed that we have not been saving the 1/sqrt(TRX) and 1/sqrt(TRY) data, so I modified the c1lsc model and added them to the DAQ channels block.  I restarted the c1lsc model, and the _DQ channels are now archived.

  9483   Tue Dec 17 21:28:36 2013 JenneUpdateLSCCM servo slow output digitized

Den just plugged an output from the common mode board into an LSC whitening board (the spare channel that used to be called "PD_XXX_I" in the LSC model).  I have modified the LSC model to reflect the new name of the new signal ("CM_SLOW"), and have added this channel to the LSC input matrix.  Koji is, I believe, adding this channel to the LSC screen in the auxiliary error signals section.  I am also adding the _OUT of the filter bank to the DAQ channels block.

  9484   Wed Dec 18 00:26:15 2013 JenneUpdateLSCXend QPD schematic investigation

I have looked at the photo of the Xend QPD from elog 9367, as well as the schematic for the board (D990272). 

Things that will need swapping out:

  • Thick film resistors in the signal path need to be changed to thin film.
  • MAX333 needs to be replaced with MAX333A.  The 333 has "ON Resistance" of 140-175 ohms, whereas the 333A has "ON Resistance" of 20-35 ohms.
  • AD797 needs to be replaced by OPA140.  The 797 is a low voltage noise op-amp, but for a diode we want low current noise.  AD797 has 2pA/rtHz at 1kHz, whereas the OP140 has 0.8fA/rtHz at 1kHz (see Zach's elog 8125 re: OPA140).

I have ordered from digikey via techmart 10 each of the MAX333A's and the OPA140's.  (4 per QPD times 2 QPDs plus 2 spares = 10).  Both of these new chips have the same footprint and pinout as the part that they are replacing, so it'll be a fairly easy task.

Next up, I need to make a LISO model for the circuit for one of the quadrants, to see what shape it'll turn out to be.  Part of this will include deciding what resistors and capacitors to put in the OPA140 gain stage. 

Right now, the AD797s say on the schematic that the gain options are different by a factor of 5, but the actual QPD has a different resistor than is on the schematic, and there is also a capacitor in parallel with each resistor, so I need to just pull those out, and pick some values that make sense to me. 

Rana and I have discussed ignoring the 2nd and 3rd gain switching options on each quadrant, as that is getting to be more fine control than we need. 

Other things on the board:

  • The 50 ohm resistors to ground for the "QPD_rtn" have all shorted.  Rana says this is good, so leave it as-is.
  • The positive input to the AD797's all have a 100 ohm resistor to ground, rather than just being connected to ground.  Why is this??

For now, I will probably just work on the QPD head, and not the whitening board.  For now, we can run with 1 stage of whitening, and if we need lower noise, we can revisit the whitening board (including replacing the thick film resistors with thin film).

When thinking about what gains I want on my gain stages, I want to have my full arm power (~700 TRX units) be ~20,000 counts from the ADC.  So, I want my single arm power (1 TRX unit) to be ~30 counts from the ADC.  This is not such a big number, so this may also require more thinking. 

ELOG V3.1.3-