40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 48 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  1847   Thu Aug 6 18:26:26 2009 JenneUpdatePSLRef Cav and PMC aligned

[Alberto, Jenne]

We aligned both the reference cavity and the PMC, each by looking at their Trans PD on Davaviewer, and adjusting the two steering mirrors to maximize the transmission power.  We got a pretty good amount of improvement for the ref cav, but since the PMC hasn't decayed a whole lot, we got a much smaller amount of improvement.

  1850   Thu Aug 6 23:29:47 2009 JenneUpdatePSLRef cav reflection PD is funky

After Alberto and I worked on aligning the reference cavity, Rob asked the important and useful question: what is the visibility of the reference cavity.  This helps tell us if we're optimally aligned or not even close.

I did a scan of the ref cav temperature, using /scripts/PSL/FSS/SLOWscan, but there seems to be no real signal is C1:PSL-FSS_RFPDDC.  As shown in Alberto's 200-day plot, it does change sometimes, but if you zoom in on the flat parts, it seems like it's not really reading anything meaningful.  I did a cursory check-out of it, but I'm not 100% sure where to go from here:  There are (as with all of these gold-box PDs) 3 outputs:  a ribbon cable (for ADC purposes I think), an SMA for the RF signal, and a BNC for the DC signal.  The photodiode is clearly working, since if you stick the Lollypop in front of the PD, the cavity unlocks.  I plugged a 'scope into the DC BNC, and it also behaves as expected: block the beam and the signal goes down; unblock the beam and the signal goes up.  Something of note is that this readout gives a positive voltage, which decreases when the beam is blocked.  However, looking at the dataviewer channel, nothing at all seems to happen when the beam is blocked/unblocked.  So the problem lies somewhere in the get-signal-to-DAQ path.  I unplugged and replugged in the ribbon cable, and the value at which the channel has been stuck changed.  Many days ago, the value was -0.5, for the last few days it's been -1.5, and after my unplug/replug, it's now back to ~ -0.5 . The other day Alberto mentioned, and made the point again today that it's a little weird that the PD reads out a negative voltage.  Hmm.

 

Do we have a tester-cable, so that instead of the ribbon cable, I can plug that connector (or pins thereof) into a 'scope?

  1860   Fri Aug 7 17:05:34 2009 JenneUpdatePSLRef cav reflection PD is funky

Quote:

we have a tester cable, but you don't want it. Instead the problem is probably at the cross-connect. The D-cable goes to a cross-connect and you can probe there with a voltmeter. If the signal is good there, trace it to the ADC. Also trend for several years to see when this happened - Yoichi may know the history better.

Also, we still need to complete the FSS RFPD task list from last year.

 

 [Jenne, Ben]

I called in the reinforcements today.  Ben came over and we looked all around at all of the cross-connects and cables relating to the FSS.  Everything looks pretty much okey-dokey, except that we still weren't getting signal in the DataViewer channels.  Finally we looked at the psl.db file, which indicates that the C1:PSL-FSS_RFPDDC channel looks at channel 21 of the ADC cross connect thing.  We followed the cable which was plugged into this, and it led to a cable which was disconnected, but laying right next to the Ref Cav refl PD.  We plugged this into the DC out SMA connection of the photodiode (which had not been connected to anything), and suddenly everything was mostly golden again in dataviewer land.  RFPDDC_F now has a signal, but RFPDDC is still flat. 

 

Even though this seems to be working now, it's still not perfect.  Rob suggested that instead of having this SMA cable going from the photodiode's DC out, we should take the signal from the ribbon cable.  So I'm going to figure out which pin of the D-connector is the DC out, and take that from the cross connect to the ADC cross connect.  This will help avoid some persnickity ground loops. 

  1871   Mon Aug 10 11:33:58 2009 JenneUpdatePSLNon-Elogged Beam dump on the PSL table - BadBadBad

Big thumbs down to whoever put a beam dump on the PSL table in front of the PMC yesterday afternoon without noting it in the elog

The offending beam dump has been removed, and the PMC relocked.

Attachment 1: commodusthumbsdown.jpg
commodusthumbsdown.jpg
  1872   Mon Aug 10 14:58:01 2009 JenneUpdatePEM2nd set of Guralp channels plugged into ADCU

The second set of Guralp channels is now plugged into the PEM ADCU, into channels which are confirmed to be working.  (Method: 1Vpp sine wave into channel, check with DataViewer).

 

Direction, Channel Name, .ini chnum, BNC plug # on ADCU

Vertical: C1:PEM-SEIS_GUR_VERT, 15023, #24

N/S (should be Y when the seismometer is put in place): C1:PEM-TEMP_2, 15001, #2

E/W (should be X when the seismometer is put in place): C1:PEM-TEMP_3, 15002, #3

 

There is IFO work going on, so I don't want to rename the channels / restart fb40m until a little later, so I'll just use the old TEMP channel names for now. 

 

There is something totally wrong with the E/W channel.  I can look at all 3 channels on a 'scope (while it's on battery, so the op-amps in the breakout box aren't grounded), and VERT and NS look fine, and when I jump around ("seismic testing"), they show spikes.  But the EW channel's signal on the 'scope is way smaller, and it doesn't show anything when I jump. 

 

I might use the handheld Guralp tester breakout box to check the seismometer.  Also, a suspicion I have is that whoever put the box back in on Friday night after our final noise measurements left the inputs shorted for this one channel.  It's the 3rd channel in the set, so it would be most likely to be stuck shorted...  Investigations will ensue.

  1873   Mon Aug 10 15:21:15 2009 JenneUpdatePSLNon-Elogged Beam dump on the PSL table - BadBadBad

Quote:

Big thumbs down to whoever put a beam dump on the PSL table in front of the PMC yesterday afternoon without noting it in the elog

The offending beam dump has been removed, and the PMC relocked.

 Maybe it was Russell Crowe

  1882   Mon Aug 10 18:12:25 2009 JenneUpdatePEM2nd set of Guralp channels plugged into ADCU

Quote:

The second set of Guralp channels is now plugged into the PEM ADCU, into channels which are confirmed to be working.  (Method: 1Vpp sine wave into channel, check with DataViewer).

 

Direction, Channel Name, .ini chnum, BNC plug # on ADCU

Vertical: C1:PEM-SEIS_GUR_VERT, 15023, #24

N/S (should be Y when the seismometer is put in place): C1:PEM-TEMP_2, 15001, #2

E/W (should be X when the seismometer is put in place): C1:PEM-TEMP_3, 15002, #3

 

There is IFO work going on, so I don't want to rename the channels / restart fb40m until a little later, so I'll just use the old TEMP channel names for now. 

 

There is something totally wrong with the E/W channel.  I can look at all 3 channels on a 'scope (while it's on battery, so the op-amps in the breakout box aren't grounded), and VERT and NS look fine, and when I jump around ("seismic testing"), they show spikes.  But the EW channel's signal on the 'scope is way smaller, and it doesn't show anything when I jump. 

 

I might use the handheld Guralp tester breakout box to check the seismometer.  Also, a suspicion I have is that whoever put the box back in on Friday night after our final noise measurements left the inputs shorted for this one channel.  It's the 3rd channel in the set, so it would be most likely to be stuck shorted...  Investigations will ensue.

 All the channels are now good, and all the names are back to making sense. 

The problem with EW2 was in fact that the alligator clip used to short the inputs during the noise test Friday night was left in the box.  Not great, but now it's taken care of, and we have recorded data of the noise of the breakout box, so we can include that in our plots to see if we're at the limit of how good we can do at subtracting noise.

 

The channels are now named thusly:

C1:PEM-SEIS_GUR_VERT  (BNC input #24, .ini channel #15023)

C1:PEM-SEIS_GUR_EW     (BNC input #3, .ini channel #15002)

C1:PEM-SEIS_GUR_NS      (BNC input #2, .ini channel #15001)

C1:PEM-SEIS_MC1_X         (BNC input #11, .ini channel #15010)

C1:PEM-SEIS_MC1_Y        (BNC input #12, .ini channel #15011)

C1:PEM-SEIS_MC1_Z       (BNC input #10, .ini channel #15009)

C1:PEM-SEIS_MC2_Y (Ranger, which for the Huddle Test is oriented VERTICALLY)   (BNC input #4, .ini channel #15003)

 

Now we wait.....and tomorrow extract the noise of each of the seismometers from this!

 

 

  1895   Thu Aug 13 00:11:43 2009 JenneUpdateIOOMode Cleaner Unlock

So that I can collect a bit of free-swinging Mode Cleaner data, I started a script to wait 14400 seconds (4 hours), then unlock the mode cleaner.  It should unlock the MC around 4am.  As soon as someone gets in in the morning, you can relock it.  I should have plenty of data by then.

  1896   Thu Aug 13 02:17:56 2009 JenneUpdateIOOMode Cleaner Alignment

When Rob and I were getting started on locking for the evening, Mode Cleaner lost lock a few times, but every time it lost lock, it took forever to reaquire, and was pretty insistent on locking in the TEM10 mode.  I proposed that the alignment might be sketchy.  I've been fiddling with the MC alignment sliders for the last hour and a half or so, but I think I'm not 100% in tune with the 3 mirror parameter space.  The mode cleaner now locks, but I'm not in love with its' alignment.  The WFS are definitely catywhompus.  Before doing hardware things like recentering the WFS, I'm going to wait until tomorrow to consult with an alignment expert.

In case this is helpful for tomorrow, before I touched any of the sliders:

Optic, Pitch, Yaw

MC1, 3.1459, -0.7200

MC3, -0.8168, -3.0700

MC2, 3.6360, -1.0576

 

Now that mode cleaner locks, although not in a great alignment:

MC1, 3.1089, -0.7320

MC3, -0.7508, -3.0770

MC2, 3.6610, -1.0786

 

If I knew how to kill my script to unlock the mode cleaner, I would.  But I sourced it, and Rob didn't know earlier this evening how to kill something which is started with 'source' since it doesn't seem to get a process number like when you './'  to run a script. So the Mode Cleaner will probably be unlocked in the morning, and it may be persnickity to get it relocked, especially if the tree people are doing tree things with giant trucks again in the morning.

  1903   Fri Aug 14 14:33:51 2009 JenneSummaryComputersnodus rebooted

Quote:

nodus was rebooted by Alex at Fri Aug 14 13:53. I launched elogd.

cd /export/elog/elog-2.7.5/
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D

 It looks like Alex also rebooted all of the control room computers.  Or something.  The alarm handler and strip tool aren't running.....after I fix susvme2 (which was down when I got in earlier today), I'll figure out how to restart those.

  1905   Fri Aug 14 15:29:43 2009 JenneUpdateComputersc1susvme2 was unmounted from /cvs/cds

When I came in earlier today, I noticed that c1susvme2 was red on the DAQ screens.  Since the vme computers always seem to be happier as a set, I hit the physical reset buttons on sosvme, susvme1 and susvme2.  I then did the telnet or ssh in as appropriate for each computer in turn.  sosvme and susvme1 came back just fine. However, I couldn't cd to /cvs/cds/caltech/target/c1susvme2 while ssh-ed in to susvme2.  I could cd to /cvs/cds, and then did an ls, and it came back totally blank.  There was nothing at all in the folder. 

Yoichi showed me how to do 'df' to figure out what filesystems are mounted, and it looked as though the filesystem was mounted.  But then Yoichi tried to unmount the filesystem, and it claimed that it wasn't mounted at all.  We then remounted the filesystem, and things were good again.  I was able to continue the regular restart procedure, and the computer is back up again.

Recap: c1susvme2 mysteriously got unmounted from /cvs/cds!  But it's back, and the computers are all good again.

  1922   Tue Aug 18 01:16:01 2009 JenneUpdatePSLMach Zehnder is realigned

The Mach Zehnder and I got to know each other today.  The reason for redoing the alignment was to improve pointing from the PSL table into the MC/IFO in hopes that this would solve the MC unlocking problems that we've been having lately.  Since Rana had aligned the IOO QPDs a few weeks ago when all of the alignments and things were good, I used them as a reference for my Mach Zehnder alignment activities. 

 
The order of operations were approximately as follows:

1. Block the secondary (west) arm of the Mach Zehnder using either an aluminum or razor dump.

2. Use SM1 in the MZ to align the beam to the IOO_QPDs (Pos and Ang).  I unfortunately also touched BS2 at this juncture, which made the refl path no longer a reference.

3.  Make sure that the QPD Sum on both Pos and Ang was sensible.  Since there are 2 beamsplitters in a Mach Zehnder, the power on the QPDs should be a quarter when only one beam is on them.  Be careful not to allow the beam no clip on anything.  The biggest problem was the bottom periscope mirror - if you hit it too high or too low, since it is a very thick optic, you end up coming out its side!  This is the frosty part on the edges, totally inappropriate for beams to go through!  Since the side of the periscope mirror isn't HR coated, when going through it like this, I was able to saturate the QPDs.  Not so good. 

4. Also, make sure that this first beam is on the MZ Refl PD.  Do this using the steering optics after the beam has left the MZ.  Use a viewer to look at the PD, and see the small spot of the beam on the diode.  We closed the iris which is present and was standing fully open to remove a spurious beam which was a parallel split-off of the main beam.  Since it was very weak, it is fine.

5.  Unblock the west arm, and block the east arm of the MZ.

6. Align this arm to both the IOO QPDs and the MZ refl diode using the adjustments on BS1, the PZT mirror and if necessary, BS2.  Note that the adjust knobs on the PZT mirror have lock screws.  Make sure to unlock them before adjusting, and relock afterward, to avoid slipping while the PZT is moving.

7.  Unblock all the beams, and make sure there is only one spot both on the transmission side and the reflection side, i.e. the 2 spots from the 2 arms are completely overlapping.  For the Trans side, make sure to look both in the near field and the far field (even after the periscope) to ensure that you really have one spot, instead of just the 2 spots crossing at a single location.

8.  Look at the MZ refl DC out and the PD out from the ISS box (which is essentially MZ trans, looking at Morag and Siobhan) on a 'scope.

9.  Touch / gently wiggle BS1 or another optic, and watch the 'scope.  At the same time, adjust BS1, the PZT mirror and BS2 to maximize the contrast between light and dark fringes.  Ideally, the refl PD should go almost to zero at the dark fringes.

10.  Check that you still have only one overlapping beam everywhere, and that you're actually hitting the MZ refl PD.

11. Because I was concerned about clipping while still figuring out the status of the lower periscope mirror, I removed the beam pipe holders between the last optic before the periscope, and the lower periscope mirror.  The beam pipe had already been removed, this was just the pedestals and the snap-in clamps.

All done for now!  Still to be done:  Optimize the position of the EOMs.  There is a waveplate out front and the EOMs are mounted in such a way that they can be moved in several directions, so that we can optimize the alignment into them.  They ideally only should see a single polarization, in order to apply solely a phase modulation on the beam.  If the input polarization isn't correct, then we'll get a bit of amplitude modulation as well, which on PDs looks like a cavity length change.  Also, the little blue pomona-type box which has the RF signals for the EOMs needs to be clamped to the table with a dog clamp, or better yet needs to be moved underneath the PSL table, with just the cables coming up to the EOMs.  The SMA connections and the SMA cable kept interfering with the MZ refl beam...it's a wonder anyone ever made the beam snake around those cables the way they were in the first place. Right now, the box is sitting just off the side of the table, just inside the doors.

 
Something else that Rana and I did while on the table:  We moved the PMC trans optics just a teensy bit toward the PSL door (to the east) to avoid coming so unbelievably close to the MZ refl optics.  The PMC trans beam shown in the lowest part of my sketch was very nearly clipping on the MZ refl steering optic just near it.  This situation isn't totally ideal, since (as it has been in the past), the first optic which is dedicated to the PMC trans isn't fully sitting on the PSL table.  The pedestal needs to hang off the edge of the table a bit to keep this beam from clipping.  Unfortunately there really isn't space to make a better beam path.  Since we're planning on getting rid of the MZ when the upgrade happens, and this isn't causing us noticeable trouble right now, we're going to let it stay the way it is.

Also, we dumped the reflection from the PMC RFPD onto a razor blade dump. And we noticed that the PZT mirror and BS2 in the MZ are badly vibrationally sensitive. BS2 has a ~400 Hz resonance (which is OK) but a ~150 ms ringdown time!! PZT mirror is similar.

Q = pi * f * tau = 200!  Needs some damping.

Attachment 1: MachZehnderOptics2.pdf
MachZehnderOptics2.pdf
  1925   Tue Aug 18 15:52:27 2009 JenneUpdatePSLMZ
I tweaked up the MZ alignment.  The reflection had been around 0.550, which kept the MEDM indicator green, but was still too high.  I fiddled with BS1, and a little bit with BS2.  When I had the doors of the PSL table open, I got as low as 0.320.  When I closed up and came back to the control room, the MZ refl had drifted up to 0.354.  But it's good again now.

In the future, mirrors shouldn't be so close together that you can't get at their knobs to adjust them No good.  I ended up blocking the beam coming out of the PMC to prevent sticking my hand in some beam, making the adjustment, then removing the dump.  It worked in a safe way, but it was obnoxious. 

  1928   Wed Aug 19 17:11:33 2009 JenneUpdateIOOQPDs aligned

Quote:

 

If Rob/Yoichi say the alignment is now good, the we absolutely must center the IOO QPDs and IP POS and IP ANG and MC TRANS  today so that we have good references.

  

 IOO_QPD_POS,    IOO_QPD_ANG,    MC_TRANS,    IP_POS, IP_ANG    have all been centered.

Also, the MCWFS have been centered.

I'm now working on making sure beam is hitting all of the RF PDs around.

  1929   Wed Aug 19 18:02:22 2009 JenneUpdateLSCRF PDs aligned

All of the LSC RF PDs have been aligned.  I didn't really change much of anything, since for all of them, the beam was already pretty close to center.  But they all got the treatment of attaching a Voltmeter to the DC out, and adjusting the steering mirror in both pitch and yaw, finding where you fall off the PD in each direction, and then leave the optic in the middle of the two 'edges'.

Before aligning each set (PO, Refl, AS), I followed the procedure in Rob's new RF photodiode Wiki Page

Also, for superstitious reasons, and in case I actually bumped them, I squished all of the ribbon cable connectors into the PDs, just in case.

  1932   Fri Aug 21 17:05:04 2009 JenneUpdateGeneralrestarted the elog

[Kevin, Jenne]

Kevin's awesome final report/elog entry was so awesome that it crashed the elog.  It has been restarted.  We're going to put his pictures and documentation in the wiki, with a link from the elog to prevent re-crashing.

  1935   Fri Aug 21 18:37:16 2009 JenneUpdateGeneralTransfer function of Mode Cleaner Stacks

Using free-swinging Mode Cleaner OSEM data and Guralp seismometers, I have taken transfer functions of the Mode Cleaner stacks.

During this experiment, the MC was unlocked overnight, and one Guralp seismometer was underneath each chamber (MC1/MC3, and MC2).  Clara will let me know what the orientation of the seismometers were (including which seismometer was underneath which chamber and what direction the seismometer axes were pointing), but for now I have included TFs for every combination of suspension motion and seismometer channels.

I combined the 4 OSEM channels for each optic in POS and PIT, and then calibrated each of my sus channels using the method described in Kakeru's elog entry 1413. Units are meters for POS, and radians for PIT.  I also calibrated the guralp channels into meters.

The traces on each plot are: MC_{POS or PIT} / Guralp_{1 or 2}_{direction}.  So each plot shows the coupling between every seismometer direction and a single mirror direction.  The colors are the same for all the plots, ie the gold trace is always Gur1Z.

Attachment 1: TF_osems_guralps.png
TF_osems_guralps.png
  1975   Tue Sep 8 17:57:30 2009 JenneUpdatePEMAll the Acc/Seis working again

All of the accelerometers and seismometers are plugged in and functional again.  The cables to the back of the accelerometer preamp board (sitting under the BS oplev table) had been unplugged, which was unexpected.  I finally figured out that that's what the problem was with half of the accelerometers, plugged them back in, and now all of the sensors are up and running.

TheSEIS_GUR seismometer is under MC1, and all the others (the other Guralp, the Ranger which is oriented vertically, and all 6 accelerometers) are under MC2.

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

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

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

Quote:

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

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

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

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

  1981   Thu Sep 10 15:55:44 2009 JenneUpdateComputersc1ass rebooted

c1ass had not been rebooted since before the filesystem change, so when I was sshed into c1ass I got an error saying that the NFS was stale.  Sanjit and I went out into the cleanroom and powercycled the computer.  It came back just fine.  We followed the instructions on the wiki, restarting the front end code, the tpman, and did a burt restore of c1assepics. 

  1982   Thu Sep 10 17:47:25 2009 JenneUpdateComputerschanges to the startass scripts

[Rana, Jenne]

While I was mostly able to restart the c1ass computer earlier today, the filter banks were acting totally weird.  They were showing input excitations when we weren't putting any, and they were showing that the outputs were all zero, even though the inputs were non-zero and the input and the output were both enabled. The solution to this ended up being to use the 2nd to last assfe.rtl backup file.  Rana made a symbolic link from assfe.rtl to the 2nd to last backup, so that the startup.cmd script does not need to be changed whenever we alter the front end code.

The startup_ass script, in /caltech/target/gds/ which, among other things, starts the awgtpman was changed to match the instructions on the wiki Computer Restart page.  We now start up the /opt/gds/awgtpman .  This may or may not be a good idea though, since we are currently not able to get channels on DTT and Dataviewer for the C1:ASS-TOP_PEM channels.  When we try to run the awgtpman that the script used to try to start ( /caltech/target/gds/bin/ ) we get a "Floating Exception". We should figure this out though, because the /opt/gds/awgtpman does not let us choose 2kHz as an option, which is the rate that the ASS_TOP stuff seems to run at.

The last fix made was to the screen snapshot buttons on the C1:ASS_TOP screen.  When the screen was made, the buttons were copied from one of the other ASS screens, so the snapshots saved on the ASS_TOP screen were of the ASS_PIT screen.  Not so helpful.  Now the update snapshot button will actually update the ASS_TOP snapshot, and we can view past ASS_TOP shots.

  1984   Fri Sep 11 17:07:45 2009 JenneUpdateAdaptive FilteringMinor changes to ASS_TOP_PEM screen.

There was some uncertainty as to which channels were being input into the Adaptive Filtering screen, so I checked it out to confirm.  As expected, the rows on the ASS_TOP_PEM screen directly correspond to the BNC inputs on the PEM_ADCU board in the 1Y6 (I think it's 6...) rack.  So C1:ASS-TOP_PEM_1_INMON corresponds to the first BNC (#1) on the ADCU, etc. 

After checking this out, I put text tags next to all the inputs on the ASS_TOP_PEM screen for all of the seismometers (which had not been there previously).  Now it's nice and easy to select which witness channels you want to use for the adaptation.

  1988   Wed Sep 16 11:58:11 2009 JenneUpdateAdaptive FilteringNew Filters for Adaptive Filtering

When Sanjit and I were looking at the adaptive filtering system on Monday and Friday, we noticed that turning on the Accelerometers (which had been used in the past) seemed to do good things, but that turning on the seismometers (which I just put into the system last week) made the OAF output integrate up.  Rana pointed out that this is an indication of a missing high pass filter.  And indeed, when I put the seismometers in, I neglected to copy the high pass filter at low frequencies, and the low pass at 64Hz from the accelerometer path to the seismometer path.  The accelerometers had a HP at 1Hz, which is okay since they don't really do useful things down to the mHz level.  I gave all of the seismometers HP at 1mHz.  These are now in the filter banks in the ASS_TOP_PEM screen.  The accelerometers are on channels 15, 16, 17, 18, 19, 20 and the seismometers are on channels 2, 3, 4, 10, 11, 12, 24.

I now need to modify the upass script to turn these filters on before doing adaptive filtering.

  1992   Fri Sep 18 16:05:08 2009 JenneOmnistructurePSLwater under the laser chiller

Quote:

rob, koji, steve

We noticed some water (about a cup) on the floor under the NESLAB chiller today.  We put the chiller up on blocks and took off the side panel for a cursory inspection, but found no obvious leaks.  We'll keep an eye on it.

 The culprit has been found:  One of the bottles of chiller water had a tiny leak in it, and apparently the floor is sloped just right to make it look like the water had been coming from under the chiller.  All is well again in the world of chilled water.

  1996   Wed Sep 23 20:02:11 2009 JenneAoGComputersGremlins in the RFM

Quote:

A cosmic ray struck the RFM in the framebuilder this afternoon, causing hours of consternation.  The whole FE system is just now coming back up, and it appears the mode cleaner is not coming back to the same place (alignment).

 

rob, jenne

 Jenne, Rana, Koji

The mode cleaner has been realigned, using a combination of techniques.  First, we used ezcaservo to look at C1:SUS-MC(1,3)_SUS(DOF)_INMON and drive C1:SUS-MC(1,3)_(DOF)_COMM, to put the MC1 and MC3 mirrors back to their DriftMon values.  Then we looked at the MC_TRANS_SUM on dataviewer and adjusted the MC alignment sliders by hand to maximize the transmission.  Once the transmission was reasonably good, we saw that the spot was still a little high, and the WFS QPDs weren't centered.  So Koji and I went out and centered the WFS, and now the MC is back to where it used to be.  The MC_TRANS QPD looks nice and centered, so the pointing is back to where it used to be.

  2000   Thu Sep 24 21:04:15 2009 JenneUpdateMOPAIncreasing the power from the MOPA

[Jenne, Rana, Koji]

Since the MOPA has been having a bad few weeks (and got even more significantly worse in the last day or so), we opened up the MOPA box to increase the power.  This involved some adjusting of the NPRO, and some adjusting of the alignment between the NPRO and the Amplifier.  Afterward, the power out of the MOPA box was increased.  Hooray! 

Steps taken:

0.  Before we touched anything, the AMPMON was 2.26, PMC_Trans was 2.23, PSL-126MOPA_126MON was 152 (and when the photodiode was blocked, it's dark reading was 23).

1.  We took off the side panel of the MOPA box nearest the NPRO, to gain access to the potentiometers that control the NPRO settings.  We selectively changed some of the pots while watching PSL-126MOPA_126MON on Striptool.

2.  We adjusted the pot labeled "DTEMP" first. (You have to use a dental mirror to see the labels on the PCB, but they're there). We went 3.25 turns clockwise, and got the 126MON to 158. 

3. To give us some elbow room, we changed the PSL-126MOPA_126CURADJ from +10.000 to 0.000 so that we have some space to move around on the slider.  This changed 126MON to 142. The 126MOPA_CURMON was at 2.308.

4.  We tried adjusting the "USR_CUR" pot, which is labeled "POWER" on the back panel of the NPRO (you reach this pot through a hole in the back of the NPRO, not through the side which we took off, like all the other pots today).  This pot did nothing at all, so we left it in its original position.  This may have been disabled since we use the slider.

5.  We adjusted the CUR_SET pot, and got the 126MON up to 185.  This changed the 126MOPA_CURMON to 2. 772 and the AMPMON to 2.45

We decided that that was enough fiddling with the NPRO, and moved on to adjusting the alignment into the Amplifier.

6.  We teed off of the AMPMON photodiode so that we could see the DC values on a DMM.  When we used a T to connect both the DMM and the regular DAQ cable, the DMM read a value a factor of 2 smaller than when the DMM was connected directly to the PD.  This shouldn't happen.....it's something on the to-fix-someday list.

7.  Rana adjusted the 2 steering mirrors immediately in front of the amplifier, inside the MOPA box.  This changed the DMM reading from its original 0.204 to 0.210, and the AMPMON reading from 2.45 to 2.55. While this did help increase the power, the mirrors weren't really moved very much.

8.  We then noticed that the beam wasn't really well aligned onto the AMPMON PD.  When Rana leaned on the MOPA box, the PD's reading changed.  So we moved the PD a little bit to maximize its readings.  After this, the AMPMON read 2.68, and the DMM read 0.220.

9.  Then Rana adjusted the 2 waveplates in the path from the NPRO to the Amplifier.  The first waveplate in the path didn't really change anything.  Adjusting the 2nd waveplate gave us an AMPMON of 2.72, and a DMM reading of 0.222.

10.  We closed up the MOPA box, and locked the PMC.  Unfortunately, the PMC_Trans was only 1.78, down from the 2.26 when we began our activities.  Not so great, considering that in the end, the MOPA power went up from 2.26 to 2.72.

11.  Koji and I adjusted the steering mirrors in front of the PMC, but we could not get a transmission higher than 1.78.

12.  We came back to the control room, and changed the 126MOPA_126CURADJ slider to -2.263 which gives a 126MOPA_CURMON to 2.503.  This increased PMC_TRANS up to 2.1. 

13.  Koji did a bit more steering mirror adjustment, but didn't get any more improvement.

14.  Koji then did a scan of the FSS SLOW actuator, and found a better temperature place (~ -5.0)for the laser to sit in.  This place (presumably with less mode hopping) lets the PMC_TRANS get up to 2.3, almost 2.4.  We leave things at this place, with the 126MOPA_126CURADJ slider at -2.263. 

Now that the MOPA is putting out more power, we can adjust the waveplate before the PBS to determine how much power we dump, so that we have ~constant power all the time.

 

Also, the PMCR view on the Quad TVs in the Control Room has been changed so it actually is PMCR, not PMCT like it has been for a long time.

  2001   Fri Sep 25 16:10:17 2009 JenneUpdateAdaptive FilteringSome progress on OAF, but more still to be done

[Jenne, Sanjit]

It seems now that we are able to get the OAF system to do a pretty good job of approximating the MC_L signal, but we can't get it to actually do any subtracting.  I think that we're not correctly setting the phase delay between the witness and the MC_L channels or something (I'm not sure though why we get a good filter match if the delay is set incorrectly, but we do get a good filter match for very different delay settings: 1, 5, 100, 1000 all seem to do equally well at adjusting the filter to match MC_L). 

The Matt Evans document in elog 395 suggests measuring the phase at the Nyquist frequency, and calculating the appropriate delay from that.  The sticking point with this is that we can't get test points for any channel which starts with C1:ASS.  I've emailed Alex to see what he can do about this.  Elog 1982 has a few words about how we're perhaps using a different awgtpman on the ass machine than we used to, which may be part of the problem. 

The golden plan, which in my head will work perfectly, is as follows: Alex will fix the testpoint problem, then Sanjit and I will be able to measure the phase between our OAF signal and the incoming MC_L signal, we will be able to match them as prescribed in the Matt Evans document, and then suddenly the Adaptive Filtering system will do some actual subtracting!

The plot below shows the Reference MC_L without any OAF system (black), the output of the OAF (green), and the 'reduced' MC_L (red).  As you can see, the green trace is doing a pretty good job of matching the black one, but the red trace isn't getting reduced at all.

Attachment 1: OAF_Running_25Sept2009.jpg
OAF_Running_25Sept2009.jpg
  2002   Fri Sep 25 16:45:29 2009 JenneUpdateMOPATotal MOPA power is constant, but the NPRO's power has decreased after last night's activities?

[Koji, Jenne]

Steve pointed this out to me today, and Koji and I just took a look at it together:  The total power coming out of the MOPA box is constant, about 2.7W.  However, the NPRO power (as measured by 126MOPA_126MON) has decreased from where we left it last night.  It's an exponential decay, and Koji and I aren't sure what is causing it.  This may be some misalignment on the PD which actually measures 126MON or something though, because 126MOPA_LMON, which measures the NPRO power inside the NPRO box (that's how it looks on the MEDM screen at least...) has stayed constant.  I'm hesitant to be sure that it's a misalignment issue since the decay is gradual, rather than a jump. 

Koji and I are going to keep an eye on the 126MON value.  Perhaps on Monday we'll take a look at maybe aligning the beam onto this PD, and look at the impedance of both this PD, and the AMPMON PD to see why the reading on the DMM changed last night when we had the DAQ cable T-ed in, and not T-ed in. 

Attachment 1: AMPMONconstant_126MONdown.jpg
AMPMONconstant_126MONdown.jpg
  2004   Fri Sep 25 19:55:59 2009 JenneUpdateAdaptive FilteringSubtraction of the microseism using Adaptive Filtering!

[Rana, Jenne]

The OAF system did something useful today!  Attached is a plot.  Black is the reference (13 averages) with the OAF off.  Blue is the output of the OAF, and red is the reduced MC_L signal (13 averages).  If you turn tau and mu both to 0, it "pauses" the filter, but keeps the feedforward system working, so that you can take a long average to get a better idea of how well things are working. If you ramp down the output of the CORR filter bank, that lets you take a long average with the OAF "off", but doesn't mess up your nicely adapted filter.  The cyan and gold traces in the upper plot are 2 of the Guralp channels, so you can see the real seismic motion.

In the lower plot, you can see that the cyan and light green seismic channels have good coherence with IOO-MC_L (the names don't really mean anything right now...these 2 seismometer channels are the 2 Guralps' channels, one per end of the MC, which are aligned with the MC.)  The dark blue trace is the coherence between IOO-MC_L and the output of the OAF.

500 taps, delay=5, 2 Guralp channels (the ones aligned with the MC), tau~0.00001 (probably), and mu~0.01 or 0.005

Attachment 1: OAF_running_WORKING_25Sept2009.png
OAF_running_WORKING_25Sept2009.png
  2006   Sat Sep 26 13:55:20 2009 JenneUpdateMZMZ was locked in a bad place

I found the MZ locked in a bad place earlier today.  It was locked in a similarly bad spot yesterday after we fixed the cable situation for 126MOPA_126MON, with reflection of ~0.8, rather than the nominal 0.305.  It's good now though. 

  2012   Mon Sep 28 11:52:23 2009 JenneUpdateTreasureOAF screen added to the screenshots webpage

I used Kakeru's instructions in elog 1221 to add the C1OAF screen (still called C1ASS_TOP) to the medm screenshots webpage.  The tricky part of this is figuring out that the file that needs editing is in fact in /cvs/cds/projects/statScreen, not /cvs/cds/caltech/statScreen, as claimed in the entry. 

  2014   Mon Sep 28 23:13:14 2009 JenneConfigurationElectronicsRob is breaking stuff....

Koji and I were looking for an extender card to aid with MZ board testing.  Rob went off on a quest to find one.  He found 2 (in addition to the one in the drawer near the electronics bench which says "15V shorted"), and put them in some empty slots in 1X1 to test them out.  Somehow, this burned a few pins on each board (1 pin on one of them, and 3 pins on the other). We now have 0 functioning extender cards: unfortunately, both extender cards now need fixing.  The 2 slots that were used in 1X1 now have yellow electrical tape covering the connectors so that they do not get used, because the ends of the burnt-off pins may still be in there. 

In other, not-Rob's-fault news, the Martian network is down...we're going to try to reset it so that we have use of the laptops again.

  2028   Wed Sep 30 12:21:08 2009 JenneUpdateComputersrestarted the elog

I'm blaming Zach on this one, for trying to upload a pic into the ATF elog (even though he claims it was small....)  Blame assigned: check.  Elog restarted: check.

  2029   Wed Sep 30 17:49:21 2009 JenneUpdateAdaptive FilteringNew UP/DOWN scripts for OAF

[Sanjit, Jenne]

The up and down scripts accessible from the OAF (still C1:ASS-TOP) screen are now totally functional and awesome.  They are under the blue ! button.  The up script can either be for the Seismometers, or the Accelerometers at this time.  The only difference between these 2 is which burt restore file they look at:  the seismometer version puts all 7 seismometer channels in the PEM selecting matrix, while the accelerometer version puts the 6 accelerometer channels in that matrix.  Both scripts also turn on HP_1mHz filters in the ERR_EMPH filter bank and all of the witness filter banks, and the AA32 and AI32 filters in ERR_EMPH, CORR and PEM filter banks.  This makes all of the starting filters the same between the witness paths and the error path.

If you want to use a different combination of sensors, run one of the up scripts, then change the PEM matrix by hand. 

The down script disables the output to the optics, and resets the adapted filter coefficients.  DO NOT use this script if you're trying to "pause" the filter to take some nice long averages.

  2034   Thu Oct 1 11:39:47 2009 JenneUpdateSUSMC2 damping restored again

Quote:

 The EQ did not change the input beam pointing. All back to normal, except MC2 wachdogs tripped again.

 Round 3 for the day of MC2 watchdogs tripping.

  2054   Mon Oct 5 18:34:26 2009 JenneUpdateAdaptive FilteringAttempts to take a TF of the OAF system

[Jenne, Sanjit]

As per Matt's instructions in his OAF document (elog 395) in the Tuning section, Sanjit and I took a transfer function measurement from the output of the OAF system, to the input.  i.e. we're trying to measure what happens out in the real world when we push on MC1, and how that is fed back to the input of our filter as MC_L.  The game plan is to measure this transfer function, and read off the phase at the nyquist frequency, and use this value to calculate the appropriate sample-and-hold delay to be used in the OAF.  The downsample rate for the OAF is 32, so that we're running at 64Hz instead of the 2048Hz of the front-end.  Thus, our Nyquist frequency is 32Hz.

                            DownSampleRate

Phase@Nyquist * ------------------------

                                    180

In the attached figure we do a swept sine from CORR_EXC to ERR_EMPH_OUT to determine the transfer function.  Here, we turn off all of the filters in both the CORR and EXC banks, because those are already matched/taken into account in the PEM filter banks. 

Using the cursor on DTT, we find that the phase at 29.85Hz is -228.8deg, and at 37.06Hz is -246.0deg.  Extrapolating, this means that at 32Hz, we expect about -234deg phase.  Using our handy-dandy formula, this means that we should try a delay of 41 or 42 (41.6 is between these two...) 

We'll give this a shot!

Attachment 1: OAF_TF_CORRexc_EMPHout_2.png
OAF_TF_CORRexc_EMPHout_2.png
  2058   Tue Oct 6 11:13:53 2009 JenneUpdateAdaptive FilteringAttempts to take a TF of the OAF system

Quote:

[Jenne, Sanjit]

As per Matt's instructions in his OAF document (elog 395) in the Tuning section, Sanjit and I took a transfer function measurement from the output of the OAF system, to the input.  i.e. we're trying to measure what happens out in the real world when we push on MC1, and how that is fed back to the input of our filter as MC_L.  The game plan is to measure this transfer function, and read off the phase at the nyquist frequency, and use this value to calculate the appropriate sample-and-hold delay to be used in the OAF.  The downsample rate for the OAF is 32, so that we're running at 64Hz instead of the 2048Hz of the front-end.  Thus, our Nyquist frequency is 32Hz.

                            DownSampleRate

Phase@Nyquist * ------------------------  =  Delay

                                    180

In the attached figure we do a swept sine from CORR_EXC to ERR_EMPH_OUT to determine the transfer function.  Here, we turn off all of the filters in both the CORR and EXC banks, because those are already matched/taken into account in the PEM filter banks. 

Using the cursor on DTT, we find that the phase at 29.85Hz is -228.8deg, and at 37.06Hz is -246.0deg.  Extrapolating, this means that at 32Hz, we expect about -234deg phase.  Using our handy-dandy formula, this means that we should try a delay of 41 or 42 (41.6 is between these two...) 

We'll give this a shot!

 As Rana pointed out to me last night, I was using continuous phase, which is not good.  When using regular phase, I find: (29.85Hz, 131.216deg), (37.06Hz, 113.963deg), so extrapolating gives (32Hz, 126.07deg).  Plugging this in to our handy-dandy formula, we get a delay of 22.4, so we should try both 22 and 23.

  2059   Tue Oct 6 20:09:50 2009 JenneOmnistructureEnvironmentRF area is clean!

I spent part of the afternoon cleaning up the area next to the Mode Cleaner where we keep all of our RF stuff:  Attenuators, BNC/SMA/LEMO adapters, Mini-Circuits items, and all sorts of other things which are useful while looking at our electronics/RF stuff.

We got another set of "Lyon" drawers, which aided in the organization process....Bob ordered 2, so we now have a 'spare' drawer set if anyone can think of something else to organize (unless this was premeditated for optics or something else?).

As you can see in the picture, (1) it's no longer a total disaster over there, and (2) some of the drawers have sub-divisions to make it faster and easier to find what you're looking for.  Please help out by putting things away in their proper place, and adding more labels or dividers to the drawers if there's something else which needs a 'spot'.

Attachment 1: DSC_0894.JPG
DSC_0894.JPG
  2065   Wed Oct 7 19:23:49 2009 JenneUpdateAdaptive Filtering(Final?) PEM cabling changes

Quote:

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

 I spiffed up the order of the cables / sensors plugged into the PEM ADCU.  Now all of the seismometers are labeled as Rana left them, and the 2 Guralp's have their sets of 3 channels next to eachother in channel-number-land.  None of the accelerometer names/cabling have changed recently.  In the table, Cable-label refers to the physical tag tied to the end of the cables plugged into the ADCU...they are meant to be descriptive of what seismometer channels they are hooked up to, and then the names change to something useful for us when they come into the DAQ system.  Also, the labels of input channels on the ASS_TOP_PEM screen have been updated accordingly.

 

Channel Name Channel Number on ADCU and OAF PEM list Cable-label .ini channel number
C1:SEIS-GUR2_X 2 Gur2 EW 15001
C1:SEIS-GUR2_Y 3 Gur2 NS 15002
C1:SEIS-GUR2_Z 4 Gur2 Vert 15003
C1:SEIS-GUR1_X 10 Gur1 EW 15009
C1:SEIS-GUR1_Y 11 Gur1 NS 15010
C1:SEIS-GUR1_Z 12 Gur1 Vert 15011
C1:SEIS-RANGER_Y 24 Ranger

15023

 

  2074   Fri Oct 9 03:53:56 2009 JenneUpdateAdaptive FilteringRemaking the ASS

The c1ass computer, which is now used for the OAF system, has many remnants from the days when it was actually used as an ASS.  These PIT and YAW filter banks and other things were taking up a lot of unnecessary space, so I deleted them in the ass.mdl file.  These files are all backed up, so we can always revert back to an older version when we want some Alignment Stabilization again someday.  I then did a make ass, following the instructions on the 40m Wiki -> Computers and Scripts -> Simulink to Front-End Code page.  Rana moved some things around, most notably all of the things (like the ASS screens) which were only in ...../users/alex/.... are now in ....../caltech/cds/advLigo/..... .  This required a few restarts of the c1ass machine (after a couple different versions of the simulink diagram....one to make sure we knew how to do it, and then again actually deleting the unused portions).

The big lesson of the night was that there are 2 signal paths for the PEM channels.  As is shown in Figure 3 in the mevans document, the PEM channels get the matching filters when they go to the adaptation algorithm, but when they go to the FIR filter, they do not get the matching filters. This is implemented by taking the output of the giant PEM matrix, and having a duplicate of each of the channels "selected for adaptation", one which gets filtered through the PEM_N_ADPT banks, and one which goes straight (in code-land) to the FIR filter.  So, it seems like all the filters which we had been including in the input side of the matrix for matching purposes need to be put in the output side.  One of the AA32 filters needs to stay in the input side, for actual anti imaging of the PEM channels, then we put the AA32 and AI32 which are for matching the ERR_EMPH and CORR filter banks up in the PEM_N_ADAPT banks.  Rana and I made these filters, and they are now turned on appropriately with the OAF down script (so that all the filters are ready and waiting for the OAF to be turned on).

A little success with getting the 3Hz peak reduced, but not a lot beyond that.  Tomorrow I'll put the accelerometers back where they used to be to see if they help out at all.

  2077   Fri Oct 9 17:37:21 2009 JenneUpdateIOOMC2 trans beam is dumped

Last night while noise hunting, Rana found that the MC2 trans beam has been left for an unknown length of time just hitting the side of the black enclosure box.  Today I put a brand-spankin'-new razor dump on the MC2 table, to dump the beam.

  2078   Fri Oct 9 17:41:04 2009 JenneUpdatePEMAccelerometers relocated

[Sanjit, Jenne]

The set of 6 accelerometers which were semi-randomly placed underneath the MC2 tank are now back into 2 separate sets of 3 - one set at MC2 and one set at MC1.  The channel names once again reflect reality, i.e. MC1_Y is actually under the MC1 tank, and aligned with the y direction.  Also, the Guralp under MC1 was moved a little bit to the left, because Sanjit wanted to put the accelerometers where the seismometer had been. 

  2084   Mon Oct 12 18:38:07 2009 JenneConfigurationSAFETYStray beam blocking

Quote:

Steve, Kiwamu, and Koji

We went through the PSL table to make sure any strong beam did not hit the wall.

We found that the reflection of Stephanie's OSA returned its path down to the beamsplitter.
This BS reflect that beam to the wall. That was fixed.

The surprising was that the relatively strong beam (~1mW?) went through the steering mirror
just before the PMC. We put thorlabs razor blades. I am still thinking what this indicates...
because the beam had been blocked if it was such from long time before.

During the work we found some stray optics such as a cube BS, a flipper mirror, and so on.
We can see them in the photo as those enclosed with yellow circles.
One of the beams was obtained from the reflection of the ND filter (...almost illeagal), and 
was even hittting a metal fixture for the BS cube.

If someone uses these components for useful purposes,
please let me(Koji) know. Otherwise, they are removed next week.

The other thing we found was the bright scatter from the EOM for the PMC.
As this scatter is so blight, I am going to align it.

 These components are from when Rana and I used the StochMon PD to do the RFAM tuning, documented in elog 1926.  This was a very handy measurement, but I'm not sure if whether or not we need it often enough to keep the optics there.

  2116   Mon Oct 19 11:31:55 2009 JenneUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

Quote:

[Rana, Jenne]

There is some craziness going on with the delay in the PEM path for the OAF.  We plot the difference between the C1:PEM-SEIS_GUR1_X and C1:ASS-TOP_PEM_10.  These are physically the same channel, plugged into the PEM ADCU, and then the signal is used as a regular PEM channel, and is also sent to the ASS computer and used there for the OAF system.  As you can see in the blue trace on the bottom plot, there is a huge amount of delay, and it's very noisy.  We also plot the _GUR2_X / ASS-TOP_PEM_2 pair (red), and it has a similar amount of delay, but it is not nearly as fuzzy and noisy.  For comparison, we plot the SUS-MC2_MCL (which is identical to IOO-MC_L) and ASS-TOP_ERR_MCL pair (green), and they don't have any big overall delay problems, so it's not totally a problem with the signals getting to the ASS computer.

This problem was present during/after all of the following attempts to fix it:

* The sample rate on the ASS computer is 2048.  The PEM channels were being acquired the ADCU at 512.  We changed the ADCU sampling rate to 2048 to match.

* We soft rebooted the ASS computer, in case it was a timing problem.

* Doing a "sudo shutdown -r now" while logged in as controls.

We might also try resetting/power cycling c0dcu in the morning.  Alex has been emailed to help us try to figure this out.

 

In other news, the time delay that we measure from the plot gives us 180degrees in ~210Hz.  This corresponds to a little more than 2msec of delay, with the C1:ASS version lagging behind the C1:PEM version.  (2 samples at 840Hz) Converting to the 2048 sampling rate, we have a delay of 4.8, so 5 front-end cycles.  Since Rana measured this morning that the delay indicated by the transfer function is 10 cycles, and this delay shows that the ASS lags the actual seismometer signal by 5 cycles, we should subtract this 5 from the 10 from the transfer function, giving us a final sample-and-hold delay of 5.  Coincidentally(?), 5 is the delay that was found in the C1:ASS-TOP screen, after it's one year of dormancy.  The point of the delay feature in the code is to help match the delay in the two signal paths: the PEM path and the output path of the filter.  Since the output has a lag of 10, and the PEM path has a lag of 5, to make them match, we artificially put in a delay of 5.

 Alex came in a week ago Friday to help figure this timing problem out, and some progress was made, although there's more to be done. 

Here are the (meager) notes that I took while he was working:

we can rename the tpchn_C1_new back to tpchn_C1, but the _new one works right now, so why change it?

need to find dcuDma.c source code...this is (?) what sends the PEM channels over to ASS.  Found:  source code is dcu.c, th
en the binary is dcuDma.o  Trying to recompile/remake dcuDma to make everything (maybe) good again.

Possibility: maybe having so many channels written to the RFM takes too long? shouldn't be  a problem, but maybe it is.  I
n the startup.cmd (or similar?) change the number of ISC modules to 1, instead of 2, since we only have one physical board
 to plug BNCs into, even though we have 2 isc boards.  c0dcu1 rebooted fine with the one isc board.  now can't get ass tes
tpoints to try the DTT timing measurement again.  rebooting fb40m to see if that helps.  fb40m is back, but we still don't
 have ASS testpoints.  Alex had to leave suddenly, so maybe more later.

Also, next possibility is that c0dcu and c1ass are not synched together properly....we should look at the timing of the AS
S machine.

 

After these adventures, the noisy trace in the timing delay (in the plot in elog 2066) has become quiet, as shown below (The blue trace, which was noisy in 2066 is now hiding behind the red trace).  However, the overall timing delay problem still exists, and we don't quite understand it.  Alex and I are meeting tomorrow morning at the 40m to try and suss this out.  Our first plan of attack is to look at the ASS code, to see if it puts any weird delays in.

Attachment 1: PEM-timing_19Oct2009.png
PEM-timing_19Oct2009.png
  2143   Mon Oct 26 17:45:34 2009 JenneUpdateAdaptive FilteringNew changes to the OAF fe code

[Alex, Jenne, Sanjit]

Alex came to the 40m today, and did several awesome things in OAF-land.

We discovered that there is, in fact, an ADC board connected to the ASS machine.  The tricky bit is that it only has a ribbon cable connector, so before we can use this ADC, we need to figure out how to make a breakout board/cable/something to connect the seismometer/accelerometer/microphone BNCs to this little board.  This is the same little board that connects the timing slave to the ASS machine.  For good or for ill, the timing slave is connected to this board via clip-doodles.  Potentially we can connect an ADC tester board to this board, and go from seismometer BNCs to clipdoodles to the tester board, but I'm not in love with the idea of utilizing clipdoodles as a semi-permanent solution until the upgrade.  I emailed Ben to see if he has a better idea, or (better yet) some spare hardware now that's the same as we'll use after the upgrade.  If we can use this ADC, it may solve our timing problem which is caused by the 110B ADC used by the PEM computer. Alex showed Sanjit and I how to connect the ASS's ADC card to the simulink diagram, when we're ready for that.

We also poked around in the code, and it seems that we can now save and restore OAF coefficients at will.  I added buttons to the OAF (ASS) screen, and Alex made it so the OAF coefficients are saved in RFM shared memory whenever you click the "save coeffs" button, and are restored when you click the "restore coeffs" button.  The buttons are the same as the 'Reset' button which has been there for a long time, so they seem to maybe have a similar problem in that you have to hold the button for a while in order for the code to realize that the button has been depressed.  We couldn't fix this easily, because it looks like our SimuLink cds stuff is a little out of date.  Some day (before/when Joe and Peter make new screens for the new 40m), we need to update these things.  Alex was concerned that it might take a while to do this, if the update broke some of the blocks that we're currently using.  Also, Sanjit and I now need to check that the coefficient-saving is going as planned.  When I have DTT open, and the OAF running, I see a certain shape to the signal which is sent to MC1 to correct for the seismic motion.  This shape includes at least several peaks at resonant frequencies that exist in our stacks/suspensions.  I can then save the coefficients, reset the active filter, and then restore the coefficients.  When I do this while watching DTT, it seems as though the general shape of the filter is restored, but none of the detailed features are.  The reason for this is still under investigation. 

The code-modifications involved a few iterations of 'remaking the ass'.

  2150   Tue Oct 27 17:58:25 2009 JenneConfigurationPEMUnknown PEM channels in the PEM-ADCU?

Does anyone know what the channels plugged in to the PEM ADCU, channels 5,6,7,8 are?  They aren't listed in the C1ADCU_PEM.ini file which tells the channel list/dataviewer/everything about all the rest of the signals which are plugged into that ADCU, so I'm not sure if they are used at all, or if they're holdovers from some previous time.  The cables are not labeled in a way that makes clear what they are.  Thanks!

  2159   Thu Oct 29 18:04:02 2009 JenneUpdateAdaptive FilteringMore work on saving coeffs on the OAF screen

[Sanjit,Jenne]

Sanjit has been working today on trying to get the OAF coefficients to save properly.  Alex got us most of the way, but right now it's looking like the filter that is being saved is totally constant (all the values are the same).  We're poking around trying to figure out why this is. 

Also, we're starting again (as we should have been for the last week or so since Alex came in to help us) to check in the TOP_XFCODE whenever we make changes to it, and when we recompile the front end code. 

  2165   Fri Oct 30 10:52:56 2009 JenneUpdatePSLHEPAs

Zach found the HEPA switch on the PSL table OFF.  He turned them on.

  2166   Sun Nov 1 17:58:44 2009 JenneUpdateGeneralUpdate on Video Switch

The current update on the Chameleon video switch is: no progress.

I connected the old laptop that Rob/Steve acquired via RS-232 serial to the back of the video switch.  I'm using P2, the same serial port that the C1AUX computer was connected to just in case there's something good about P2 vs. P1. 

I used HyperTerminal to (try to) talk to the switch.  Settings were:  COM1, bits per second = 9600, data bits = 8, parity = none, stop bits = 1, flow control = none.  I can successfully send/get back responses to the basic commands, I (inquiry as to the type of equipment), and H (help - spits out the list of acceptable commands).  But when I try to do an actual command to do some video switching, everything hangs.  The front panel's rolling display (which just echos the company name) stops, then starts up again after ~20sec.  The hyperterminal display doesn't change.  I get neither the "DONE" answerback, which would indicate that the command executed successfully, nor do I get the "ERROR" answerback, which would indicate that something is wrong.  It just hangs.  If I disconnect, and restart the connection, and instead of trying a real command, but instead just send 'blahblahblah', then it will answerback 'ERROR' the first time, and then if I try to send another garbage message, everything hangs again.  So, I can sort of talk to the video switch, but I can't make it do anything yet.

I'm leaving the laptop connected instead of C1AUX, since the video EPICS screen doesn't work anyway for now.  If you want to start up the connection, either input the settings quoted above, or open "40m Video", which should have these connection settings saved in HyperTerminal.

ELOG V3.1.3-