40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 304 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  2874   Mon May 3 19:21:43 2010 AlbertoDAQEnvironmentBoot fest

[Alberto, Koji, Rana]

The RFM network failed today. We had to reboot the frame builder anf restart all the front end following the instructions for the "Nuclear Option".

Burt-restoring to May 1st at 18:07, or April 30 18:07 made c1sosvme crash. We had to reset the front ends again and restore to April 15th at 18:07 in order to make everything work.

Everything seems fine again now.

  1726   Wed Jul 8 19:42:37 2009 ClaraUpdatePEMBonnie moved to PSL, getting some coherence with the PMC_ERR channel

In her position overlooking whichever table it is that is next to the PSL, Bonnie drummed up some decent coherence with the PSL-PMC_ERR channel, but not so much with the MC_L. I moved her into the PSL itself, and now there is rather good coherence with the PMC_ERR channel, but still not so great for MC_L.

DSC_0567.JPG

Bonnie's new home in the PSL.

Attachment 2: bonnie2_pmcerr.pdf
bonnie2_pmcerr.pdf
Attachment 3: bonnie_PSL.pdf
bonnie_PSL.pdf
  1727   Thu Jul 9 02:18:09 2009 ranaUpdatePEMBonnie moved to PSL, getting some coherence with the PMC_ERR channel
My guess is that we need a different acoustic strategy. The microphones are mainly for high frequencies,
so you should not expect any coherence with MC_L (or even better, MC_F) below 100 Hz. I expect that the
main coherence for MC_F will come from the PSL in that band.

After subtracting that one out, we should look at the signal from the lock of the X or Y arm, and see
if we can nail that by putting a mic right above the AS table (leaving enough room to take the lid off).
If that works OK, we can find a spot under the lid and se if it gets better.
  1715   Thu Jul 2 16:45:06 2009 ClaraUpdatePEMBonnie and Clyde are officially in operation! (Butch Cassidy and the Sundance Kid are in temp position)

I hooked up Bonnie and Clyde last night and tested it today. First I tried some loud noises to make sure I could identify them on the readout. Then, Steve suggested I try to look for some periodic stuff. I set up Butch Cassidy and the Sundance Kid on the cabinets by the MC2 optic. Now for graphs!

 

bonnie_test_marked.png

I tapped on the microphone a few times. I also yelled a bit, but this is sampling by seconds, so perhaps they got overwhelmed by the tapping.

bonnie_test2_marked.png

This time I tried some more isolated yells. I started with a tap so I'd be sure to be able to recognize what happened. Apparently, not so necessary.

bonniebutch_2sbeat_marked.png

Here, it looks like a pretty strong periodic pattern on the second mic (Butch Cassidy). I replaced the lines with dashed ones where the pattern was a little less clear. Possibility interference from something. Mic1 (Bonnie) seems to show a pretty regular beat pattern, which seems reasonable, as it isn't particularly close to any one instrument fan.

 

So, anyway. I thought those were neat. And that I wanted to share.

 

  10222   Wed Jul 16 22:17:40 2014 AkhilSummaryElectronicsBode Plots and complete Characterization of Frequency Counter

Goal:

To estimate the transfer function and the noise in the FC that is a part of the FOL-PID loop.

Measurements Taken:

The setup used for the measurements is described in my previous elogs.

The input modulation signal and the FC output were recorded simultaneously for a certain period of time and the phase and gain are estimated from the data.

Analysis(Data and code attached):

The recordings must contain equal number of data points(around 6000 data points in my measurements) for analysis.

The steps I followed to generate these plots are:

  • Took the FFT of both FC out data(from FC) and Modulation input(from SRS via ADC).
  • Estimated the phase angles at the particular modulation frequencies from the FFT data(in Matlab using  angle(x) for phase at the frequency f(x);x: is the frequency bin)
  • Then for the phase of the system at a particular modulation frequency, 

                              Phase(system) =Phase(FC Signal) - Phase(Input Signal)

  • Plotted the acquired phase vs the modulation frequency on a Semi-log graph.

Results:

From the plots its can be inferred that :the delay of the FC is almost 0 until the modulation of 0.1 Hz. Then there are phase shifts of  +/- 180 degrees showing that the system has multiple poles and zeroes(will be estimated after I have phase plots at few more carrier frequencies).

To Do Next

Phase plots for varying carrier frequencies and different sampling times.

Installation of FC inside the 40m.

Attachment 1: Phase_Data.zip
Attachment 2: Bode100MHz.png
Bode100MHz.png
  10223   Wed Jul 16 23:02:16 2014 KojiSummaryElectronicsBode Plots and complete Characterization of Frequency Counter

If I assume 1sample delay for 0.1s sampling rate, the delay is Exp[-I 2 pi f T], where T is the sampling period.

This means that you expect only 36 deg phase delay at 1Hz. In reality, it's 90deg. Huge!

Also there are suspicious zeros at ~1.6Hz and ~3Hz. This may suggest that the freq counter is doing some
internal averaging like a moving average.

It would be interesting to apply a theoretical curve on the plot. It's an intellectual puzzle.

  5195   Thu Aug 11 16:09:05 2011 NicoleSummarySUSBode Plot for TT Suspension

All of my plots have already taken into account the calibration of the photosensor (V/mm ratio)

Here is a bode plot generated for the transfer function measurements we obtained last night/this morning. This is a bode plot for the fully-assembled T.T. (with flexibly-supported dampers and bottom bar). I will continue to upload bode plots (editing this post) as I finish them but for now I will go to sleep and come back later on today.

 

flexwithbase.jpg

Here is a bode plot comparing the no eddy-current damper case with and without the bar that we suspected to induce some non-uniform damping. We have limited data on the NO EDC, no bar measurements (sine swept data from 7 Hz to 50 Hz) and FFT data from 0 Hz to 12.5 Hz because we did not want to induce too much movement in the mirror (didn't want to break the mirror).  This plot shows that there is not much difference in the transfer functions of the TT (no EDC) with and without the bar.

stage1.jpg.jpg

From FFT measurements of  the no eddy-current damper case without the bar (800 data points, integrated 10 times) we can define the resonance peak of the TT mirror (although there are still damping effects from the cantilever blades).

The largest resonance peak occurs at about 1.94 Hz. The response (magnitude) is 230.

The second-largest resonance peak occurs at about 1.67 Hz. The response (magnitude) is 153. This second resonance peak may be due to pitch motion coupling (this is caused by the fact that the clamping attaching the mirror to the wires occurs above the mirror's center of mass, leading to inevitable linear and pitch coupling).

 

Here is a bode plot of the EDC without the bar. It seems very similar to the bode plot with the bar

FULL_BODE.jpg

 

 Here is a bode plot of the rigidly-supported EDC, without bar. I need to do a comparison plot of the rigid and flexibly-supported EDCs (without bar)

 

 FULL_BODErigid.jpg

 

Attachment 1: flexwithbase.jpg
flexwithbase.jpg
Attachment 3: stage1.jpg
stage1.jpg
  5206   Fri Aug 12 14:15:07 2011 NicoleSummarySUSBode Plot for TT Suspension

Here is my bode plot comparing the flexibly-supported and rigidly-supported EDCs (both with no bar)

It seems as if the rigidly-supported EDC has better isolation below 10 Hz (the mathematically-determined Matlab model predicted this...that for the same magnet strength, the rigid system would have a lower Q than the flexible system). Above 10 Hz (the resonance for the flexibly-supported EDCs seem to be at 9.8 Hz) , we can see that the flexibly-supported EDC has slightly better isolation? I may need to take additional measurements of the transfer function of the flexibly-supported EDC (20 Hz to 100 Hz?)  to hopefully get a less-noisy transfer function at higher frequencies. The isolation does not appear to be that much better in the noisy region (above 20Hz). This may be because of the noise (possibly from the electromagnetic field from the shaker interfering with the magnets in the TT?). There is a 3rd resonance peak at about 22 Hz. I'm not sure what causes this peak...I want to confirm it with an FFT measurement of the flexibly-supported EDC (20 Hz to 40 Hz?)

 

 

EXPrigidvsflex.jpg

 

 

  5208   Fri Aug 12 15:34:16 2011 NicoleSummarySUSBode Plot for TT Suspension

Quote:

Here is my bode plot comparing the flexibly-supported and rigidly-supported EDCs (both with no bar)

It seems as if the rigidly-supported EDC has better isolation below 10 Hz (the mathematically-determined Matlab model predicted this...that for the same magnet strength, the rigid system would have a lower Q than the flexible system). Above 10 Hz (the resonance for the flexibly-supported EDCs seem to be at 9.8 Hz) , we can see that the flexibly-supported EDC has slightly better isolation? I may need to take additional measurements of the transfer function of the flexibly-supported EDC (20 Hz to 100 Hz?)  to hopefully get a less-noisy transfer function at higher frequencies. The isolation does not appear to be that much better in the noisy region (above 20Hz). This may be because of the noise (possibly from the electromagnetic field from the shaker interfering with the magnets in the TT?). There is a 3rd resonance peak at about 22 Hz. I'm not sure what causes this peak...I want to confirm it with an FFT measurement of the flexibly-supported EDC (20 Hz to 40 Hz?)

 

 

EXPrigidvsflex.jpg

 

 

 Since the last post, I have found from the Characterization of TT data (from Jenne) that the resonant frequency of the cantilever springs for TT #4 (the model I am using) have a resonant frequency at 22 Hz. They are in fact inducing the 3rd resonance peak.

 

Here is a bode plot (CORRECTLY SCALED) comparing the rigidly-supported EDCs (model and experimental transfer functions)

RIGIDexp_model.jpg

 

Here is a bode plot comparing the flexibly-supported EDCs (model and experimental transfer functions). I have been working on this graph for FOREVER and with the set parameters, this is is close as I can get it (I've been mixing and matching parameters for well over an hour > <). I think that experimentally, the TTs have better isolation than the model because they have additional damping properties (i.e. cantilever blades that cause resonance peak at 22 Hz). Also, there may be a slight deviation because my model assumes that all four EDCs are a single EDC.

flexmodcomp.jpg

  3301   Tue Jul 27 18:42:57 2010 GopalUpdateOptic StacksBode Magnitude Plot and Concerns

I completed the frequency domain analysis mentioned previously in the x-direction. Although I ran it from 1-10 Hz, with 0.1-Hz increments, COMSOL was unable to complete the task past 7 Hz because the relative error was beyond the relative tolerance. To solve this issue, I'd have to rerun the simulation with a finer mesh, an unfavorable option because of the already-extensive run times. The Bode magnitude plot from this simulation is attached:

Bode_Mag_MC1_MC3.png

 

This simulation raises some questions about the feasibility of this method:

 

1) Do we have the computing power necessary?

 

I already moved my work from my personal Mac Pro to Kallo (4 GB --> 12 GB RAM difference). Now, instead of crashing the program constantly, I typically wait a half hour for a standard run of the model. Preferably, I could move my work to Megatron or some other workhorse-computer... but I also know that many of the big boys are already being strained as is.

 

2) Is it possible to take measurements through Matlab?

 

This way, I could write a script to instruct COMSOL and just run a few tests at a time overnight. Also, I wouldn't have to sit and record measurements manually as I've done here. The benefits of such an improvement warrant further attention. I'll work on this option next.

 

3) Up until what frequency do we need to model?

 

As I've shown, normal meshing yields data up to 7 Hz. Is this enough? Do we need more data? Certainly not less, I'm quite sure. We need to keep in mind that as frequency range increases, run times increase exponentially.

 

4) How do we incorporate gravity into the equation?

 

Gravity will produce a bit of extra force in the non-restoring direction for off-axis deviations, slightly decreasing the expected frequency. Whether or not this is an important effect is questionable, since the deviations are typically on the order of a micron, which is orders of magnitude smaller than the initial displacement I'm using on the base. I've decided to ignore this complication for now.

 

 

  3304   Wed Jul 28 01:05:44 2010 ranaUpdateSEIBode Magnitude Plot and Concerns

1) Gravity has to be included because the inverted pendulum effect changes the resonant frequencies. The deflection from gravity is tiny but the change in the dynamics is not. The results are not accurate without it. The z-direction probably is unaffected by gravity, but the tilt modes really feel it.

2) You should try a better meshing. Right now COMSOL is calculating a lot of strain/stress in the steel plates. For our purposes, we can imagine that the steel is infinitely stiff. There are options in COMSOL to change the meshing density in the different materials - as we can see from your previous plots, all the action is in the rubber.

3) I don't think the mesh density directly limits the upper measurement frequency. When you redo the swept-sine using the matlab scripting, use a logarithmic frequency grid like we usually do for the Bode plots. The measurement axis should go from 0.1 - 30 Hz and have ~100 points.

In any case, the whole thing looks promising: we've got real solid models and we're on the merge of being able to duplicate numerically the Dugolini-Vass-Weinstein measurements.

  3306   Wed Jul 28 12:16:03 2010 GopalUpdateSEIBode Magnitude Plot and Concerns

Quote:

1) Gravity has to be included because the inverted pendulum effect changes the resonant frequencies. The deflection from gravity is tiny but the change in the dynamics is not. The results are not accurate without it. The z-direction probably is unaffected by gravity, but the tilt modes really feel it.

2) You should try a better meshing. Right now COMSOL is calculating a lot of strain/stress in the steel plates. For our purposes, we can imagine that the steel is infinitely stiff. There are options in COMSOL to change the meshing density in the different materials - as we can see from your previous plots, all the action is in the rubber.

3) I don't think the mesh density directly limits the upper measurement frequency. When you redo the swept-sine using the matlab scripting, use a logarithmic frequency grid like we usually do for the Bode plots. The measurement axis should go from 0.1 - 30 Hz and have ~100 points.

In any case, the whole thing looks promising: we've got real solid models and we're on the merge of being able to duplicate numerically the Dugolini-Vass-Weinstein measurements.

I made some progress on a couple issues:

1) I figured out how to create log-transfer function plots directly in COMSOL, which eliminates the hassle of toggling between programs.

2) Instead of plotting maximum displacement, which could lead to inconsistencies, I've started using point displacement, standardizing to the center of the top surface.

3) I discovered that the displacement can be measured as a field vector, so the minor couplings between each translational direction (due to the asymmetry in the original designs) can be easily ignored. 

Bode_Disp_MC1_MC3_y.png

  12221   Tue Jun 28 16:10:49 2016 PrafulUpdateGeneralBluebird Microphones

Found 1 out of 2 bluebird microphones in the 40m.

  3586   Sun Sep 19 18:09:09 2010 ranaConfigurationCamerasBlue IP Camera installed on the PSL table

Untitled.png

I installed the blue IP camera from ZoneNet onto the PSL table. It gets its power from the overhead socket and connects via Cat5 to the Netgear switch in the PSL/IO rack.

You can connect to it on the Martian network by connecting to http://192.168.113.201:3037. Your computer must have Java working in the browser to make that work.

So far, this works on rossa, but not the other machines. It will take someone with Joe/Kiwamu level linux savvy to fix the java on there. I also don't know how to fix the host tables, so someone please add this camera to the list and give it a name.

As you can see from the image, it is  illuminating the PSL with IR LEDs. I've sent an email to the tech support to find out if we can disable the LEDs.

  6564   Tue Apr 24 22:16:59 2012 DenUpdatePEMBlue Bird Pre-Amplifier

 I detached Clyde (pre-amp that was in the control room) to understand why it is not working. I seems that the board circuit is burnt near R40, R47, R45.

DSC_4273.JPG     DSC_4274.JPG

  6566   Wed Apr 25 11:45:34 2012 JenneUpdatePEMBlue Bird Pre-Amplifier

It looks like we should change the "R40" and "R47" diodes.  If you do it this week, ask Jamie or Koji to check that you've got them oriented correctly before soldering them and plugging it in.

  6567   Wed Apr 25 18:59:47 2012 ranaUpdatePEMBlue Bird Pre-Amplifier

Usually R is for resistors and D is for diodes. Do you think from the schematic that we should put diodes into the R slots?

  6568   Wed Apr 25 19:32:57 2012 DenUpdatePEMBlue Bird Pre-Amplifier

Quote:

Usually R is for resistors and D is for diodes. Do you think from the schematic that we should put diodes into the R slots?

 That guys are resistors.

  6572   Thu Apr 26 11:56:10 2012 DenUpdatePEMBlue Bird Pre-Amplifier

Quote:

Quote:

Usually R is for resistors and D is for diodes. Do you think from the schematic that we should put diodes into the R slots?

 That guys are resistors.

 You are right, they just looked like they were too small to be resistors when I glanced at them. 

  12653   Thu Dec 1 02:19:13 2016 gautamUpdateLSCBinary output breakout box restored

As we suspected, the binary breakout board (D080478, no drawing available) is simply a bunch of tracks printed on the PCB to route the DB37 connector pins to two IDE50 connectors. There was no visible damage to any of the tracks (some photos uploaded to the 40m picasa). Further, I checked the continuity between pins that should be connected using a DMM.

I got a slightly better understanding of how the binary output signal chain is - the relevant pages are 44 and 48 in the CONTEC manual. The diagram on pg44 maps the pins on the DB37 connector, while the diagram on pg 48 maps how the switching actually occurs. The "load" in our case is the 4.99kohm resistor on the PD whitening board D000210. Following the logic in the diagram on pg48 is easy - setting a "high" bit in the software should pull the load resistor to 0V while setting a "low" bit keeps the load at 15V (so effectively the whole setup of CONTEC card + breakout board + pull-up resistor can be viewed as a simple NOT gate, with the software bit as the input, and the output connected to the "IN" pin of the MAX333).

Since I was satisfied with the physical condition of the BO breakout board, I re-installed the box on 1X5. Then, with the help of a breakout board, I diagnosed the situation further - I monitored the voltage to the pins on the backplane connector to the whitening boards while switching the MEDM switches to toggle the whitening state. For all channels except ITMY UL, the behaviour was as expected, in line with the preceeding paragraph - the voltage swings between ~0V and ~15V. As mentioned in my post yesterday, the ITMY UL channel remains dodgy, with voltages of 12.84V (bit=1) and 10.79V (bit=0). So unless I am missing something, this must point to a faulty CONTEC card? We do have spares, do we want to replace this? It also looks like this problem has been present since at least 2011...

In any case, why should this lead to ITMY UL glitching? According to the MAX333 datasheet, the switch wants "low"<0.8V and "high">2.4V - so even if the CONTEC card is malfunctioning and the output is toggling between these two states, the condition should be that the whitening stage is always bypassed for this channel. The bypassed route works just fine, I measured the transfer function and it is unity as expected.

So what could possibly be leading to the glitches? I doubt that replacing the BO card will solve this problem. One possibility that came up in today's meeting is that perhaps the +24V to the Sat. Box. (which is used to derive the OSEM LED drive current) may be glitching - of course we have no monitor for this, but given that all the Sat. Amp. Adaptor boards are on 1X5 near the Acromag, perhaps Lydia and Johannes can recommission the PSL diagnostic Aromag to a power supply monitoring Acromag?


What do these glitches look like anyway? Here is a few second snapshot from one of the many MC1 excursions from yesterday - the original glitch itself is very fast, and then that gives an impulse to the damping loop which eventually damps away.

And here is one from when there was a glitch when the tester box was plugged in to the ITMY signal chain (so we can rule out anything in the vacuum, and also the satellite box itself as the glitches seem to remain even when boxes are shuffled around, and don't migrate with the box). So even though the real glitch happens in the UL channel (note the y axes are very different for the channels), the UR, LR and LL channels also "feel" it. recall that this is with the tester box (so no damping loops involved), and the fact that the side channel is more immune to it than the others is hard to explain. Could this just be electrical cross-coupling?

Still beats me what in the signal chain could cause this problem.


Some good news - Koji was running some tests on the modified WFS demod board and locked the IMC for this. We noticed that MC1 seemed well behaved for extended periods of time unlike last night. I realigned the PMC and IMC, and we have been having lock streches of a few hours as we usually have. I looked at the MC1 OSEM PD readbacks during the couple of lock losses in the last few hours, and didn't notice anything dramatic laugh. So if things remain in this state, at least we can do other stuff with the IFO... I have plugged in the ITMY sat. box again, but have left the watchdog disabled, lets see what the glitching situation is overnight... The original ITMY sat. box has been plugged into the ETMY DAQ signal chain with a tester box. The 3 day trend supports the hypothesis the sat. box is not to blame. So I am plugging the ETMY suspension back in as well...

Attachment 4: ULcomparison.pdf
ULcomparison.pdf
  12652   Wed Nov 30 17:08:56 2016 gautamUpdateLSCBinary output breakout box removed

[ericq, gautam]

To diagnose the glitches in OSEM readouts, we have removed one of the PCIE BO D37 to IDE50 adaptor boxes from 1X5. All the watchdogs were turned off, and the power to the unit was cut before the cables on the front panel were removed. I am working on the diagnosis, I will update more later in the evening. Note that according to the c1sus model, the box we removed supplies backplane logic inputs that control whitening for ITMX, ITMY, BS and PRM (in case anyone is wondering/needs to restore damping to any of these optics). The whitening settings for the IMC mirrors resides on the other unit in 1X5, and should not be affected.

  3534   Tue Sep 7 15:31:28 2010 josephb, alexUpdateCDSBinary Output working/ IO chassis fixed

As noted previously, we were having problems with getting multiple 32 channel binary output cards working.  Alex came by and we eventually tracked the problem down to an incorrect counter in the c code.  This has been fixed and checked into the CDS svn repository.  I tested the actual hardware and we are in fact able to turn our test LEDs on with multiple binary output boards.

 

Alex and I also looked at the non-functional IO chassis (the one which wouldn't sync with the 1PPS signal and wasn't turning on when the computer turned on.  We discovered one corner of the trenton board wasn't screwed down and was in fact slightly warped.  I screwed it down properly, straightening the board out in the process.  After this, the IO chassis worked with a host interface board to the computer and started properly.  We were able to see the boards attached as well with lspci.  So that chassis looks to be in working condition now.

Onwards to the RFM test.

  4754   Fri May 20 03:29:04 2011 kiwamuUpdateCDSBinary IO box on 1X5 : LEDs off

[Steve / Kiwamu]

 When Steve was working on the strain reliefs on 1X5 he found that some LEDs on the back side of the binary IO boxes were off.

There are 4 binary IO boxes and their power are directly supplied from Sorensens. According to the display of the Sorensens, the power are correctly generated.

Steve and I checked a picture of the boxes taken before he started working and we found it's been like this.

It might be just a problem of the LEDs or the fuses are blown, but anyway it needs an inspection.

Here is a picture of the back side of the boxes. You can see some LEDs are on and some are off.

DSC_3050_small.jpg

  13167   Fri Aug 4 18:25:15 2017 gautamUpdateGeneralBilinear noise coupling

[Nikhil, gautam]

We repeated the test that EricQ detailed here today. We have downloaded ~10min of data (between GPS times 11885925523 - 11885926117), and Nikhil will analyze it.

Attachment 1: bilinearTest.pdf
bilinearTest.pdf
  13169   Mon Aug 7 16:00:41 2017 ranaUpdateGeneralBilinear noise coupling

These are not the angular test parameters that we're looking for:

 recall that what we want is the low frequency beam spot variations and the feedback to be limited to a small high frequency band.

e.g. only inject noise at 40-50 Hz, not loud enough to find at 2x the injected frequency.

It should NOT be the case that the high frequency injected noise be dominating the RMS.

The coupling should be ~1e-3; some combination of beam spot mis-centering and beam spot motion.

  12059   Fri Apr 1 13:11:26 2016 ericqUpdateWienerFilteringBilinear Noise Testing

I've been banging my head against bilinear noise subtraction, and figured I needed to test things on some real hardware to see if what I'm doing makes sense.


I ran the ASS dither alignment on the Y arm, which ensures that the beam spots are centered on both mirrors. 

I then drove ITMY in yaw with some noise bandpassed from 30-40 Hz. It showed the expected bilinear upconversion that you expect from angular noise on a centered beam, which you can see from 60-80 Hz below

I looked at the length signal, as the noise subtraction target, and the ITMY oplev yaw signal plus the transmon QPD yaw signal as witnesses.

There is some linear coupling to length, which means the the centering isn't perfect, and the drive is maybe large enough to displace it off center. However, the important part is the upconverted noise which is present only in the length signal. The QPD and oplev signals show no increased noise from 60-80Hz above the reference traces where no drive is applied

I then compared the multicoherence of those two angular witnesses vs. the multicoherence of the two (linear) witnesses plus their (bilinear) product. Including the bilinear term clearly shows coherence, and thereby subtraction potential, at the upconverted noise hump. 

So, it looks like the way I'm generating the bilinear signals and calculating coherence in my code isn't totally crazy.

Attachment 1: bilinear_drive.pdf
bilinear_drive.pdf
Attachment 2: 40m_bilin.pdf
40m_bilin.pdf
  4984   Mon Jul 18 20:59:19 2011 JenneUpdateLSCBig ol' mess

[Jamie, Jenne]

We decided to take on the deceptively easy-sounding task of checking that the LSC whitening switching was happening as anticipated.  We hoped to discover that when we clicked the "unwhitening" switches in FM1 of the LSC PDs, we would see the analog whitening turn on and off for the matching channel.  That is what is supposed to happen.

Tragically, it is instead one big giant crazy disaster of a mess.

What we did:

Made a 24tapus (octopus like last time, except more...), with a 50kOhm resistor as our white noise source (instead of using a DAC channel and AWG). 

We plugged our 24tapus into the 3 of 4 whitening boards on the LSC rack that are currently in use.  One of the boards just has 8 terminators on the input, so we left that one alone for now. 

We put the whitening gains to 0dB so that all the channels looked the same. 

We looked at the PD _IN1 channels in DTT, and monitored which signals had whitening switching when we clicked the "unwhitening" buttons on the PD filter banks. 

So far, we can find no rhyme or reason as to why some of the channels work (click unwhite on that PD, see that signal have whitening switching), and others don't.  Some channels we just can't get to switch no matter what, others are just mis-mapped.  There is no discernible pattern.

What we think (so far) is going on:

All of the cables from the PD demod boards are going to the Whitening board inputs, exactly as in Suresh's Diagram.  The only difference is that Refl33, AS165 and Refl165 demod boards don't exist in the rack at this time. 

The Whitening and AA boards in Suresh's Diagram labeled 0-7 are connected to Binary Output channels 0-7. This is a good thing.

The Whitening and AA boards in the diagram labeled 8-15 are connected to Binary Output channels 24-31. This is not so awesome.

This is all we are confident about at this time.

Next steps:

We are hoping that Ben has a secret stash (or can tell us who would) of LSC rack wiring diagrams.  We would like to find out, without the pain of tracing wires and cables by hand, how the Binary I/O information gets through the cross-connect on the LSC rack up to the whitening boards. 

We are leaving the 24tapus in place for now, so that we can carry on tomorrow, either with a wiring diagram in hand, or carefully tracing cables. 

  4988   Tue Jul 19 10:18:24 2011 ranaUpdateLSCBig ol' mess

Remember, as per our marker board conversation, that the resistor noise as excitation method only works if the gain of all of the channels is set to something high (like 45 dB).

At 0 dB, the resistor noise is only 30 nV/rHz, whereas the ADC noise is more like 10000 nV/rHz...

  3671   Thu Oct 7 16:21:02 2010 KojiOmnistructureCDSBig 3

Both Rolf and Alex (at least his elbow) together visited the 40m to talk with Joe for the CDS.

40m is the true front line of the CDS development!!!

Attachment 1: IMG_3642.jpg
IMG_3642.jpg
  6011   Fri Nov 25 22:11:12 2011 MirkoUpdateCDSBeware of fancy filter modules

[Rana, Den, Mirko]

It seems you can shoot yourself in the foot if your filter modules are too complex.

Den discovered this when looking into the C1:SUS-MC?_SUSPOS filter module named Cheby, consisting of cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501) by noticing that the coherence between input and output of the filter is low.

Cheby filter:

Cheby.png

CoherenceCheby.pdf

This is most likely due to the filter spanning more than the 16 orders of precision that the double data type spans.

The coherence is fine when one splits the filter in two, giving every cheby1 filter its own module. The coherence is also fine when you use the Cheby filter in a 2kHz system, although the freq. response looks very odd

Black: 16kHz, Red 2kHz (yes the filter was converted correctly, no text file editing there)

ChebyAt16kHzBlackand2kHzRed.png

The problem occurs on c1lsc as well as c1sus computer.

 

Looking into the foton files actually points to a precision problem, with the huge range of scale covered in there:

C1:MCS 16kHz (Cheby: Original filter with low coherence. CHbyTST & ChebyTST: Original filter split amongst two filter modules)
################################################################################
### SUS_MC3_LSC                                                              ###
################################################################################
# DESIGN   SUS_MC3_LSC 0 zpk([0],[30],0.333333,"n")
# DESIGN   SUS_MC3_LSC 1 cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 2 cheby1("LowPass",2,0.1,3)gain(1.13501) \
#                       
# DESIGN   SUS_MC3_LSC 3 cheby1("LowPass",2,0.1,3)gain(1.13501)cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
###                                                                          ###
SUS_MC3_LSC 0 12 1  32768      0 30:0.0          9.942903833923793  -0.9885608209680459   0.0000000000000000  -1.0000000000000000   0.0000000000000000
SUS_MC3_LSC 1 21 3      0      0 CHbyTST     9.095012702673064e-18  -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 2 12 1  32768      0 ChebyTST    1.228759186937126e-06  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
                                                                 -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 4 12 8  32768      0 BounceRoll     0.9991466189294013  -1.9996634951844035   0.9997010181703262  -1.9999611719719754   0.9999999999999997
                                                                 -1.9999303040590390   0.9999684339228864  -1.9999605309876360   0.9999999999999999
                                                                 -1.9999248796830529   0.9999668732412945  -1.9999594299327190   1.0000000000000002
                                                                 -1.9996385459838455   0.9996812069238987  -1.9999587601905868   1.0000000000000000
                                                                 -1.9996161812709703   0.9996978939989944  -1.9999163485656493   0.9999999999999999
                                                                 -1.9998855694973159   0.9999681878303275  -1.9999154056705493   0.9999999999999998
                                                                 -1.9998788577090287   0.9999671193335300  -1.9999137972442669   1.0000000000000000
                                                                 -1.9995951159123118   0.9996843310430819  -1.9999128255920269   1.0000000000000000

C1:OAF 2kHz
###############################################################################
### YARM_IN                                                                  ###
################################################################################
# DESIGN   YARM_IN 0 zpk([0],[30],0.333333,"n")
# DESIGN   YARM_IN 3 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)
# DESIGN   YARM_IN 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
# DESIGN   YARM_IN 8 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)zpk([],[10],1,"n")
###                                                                          ###
YARM_IN  0 12 1   4096      0 30:0.0           9.56649943398763  -0.9119509539166185   0.0000000000000000  -1.0000000000000000   0.0000000000000000
YARM_IN  3 12 4   4096      0 Cheby       1.829878084970283e-16  -1.9828889048300398   0.9830565293861987   2.0000000000000000   1.0000000000000000
                                                                 -1.9868188576622443   0.9875701115261976   2.0000000000000000   1.0000000000000000
                                                                 -1.9940934073784453   0.9954330165532327   2.0000000000000000   1.0000000000000000
                                                                 -1.9781245722853238   0.9784022621062476   2.0000000000000000   1.0000000000000000

Attachment 1: ChebyTST3.png
ChebyTST3.png
  6013   Sat Nov 26 02:05:43 2011 MirkoUpdateCDSBeware of fancy filter modules

 

We replaced the complicated Cheby filter module with three separate filter modules. Probably the filter doesn't need to be so complicated, but rather not change too many things at once. The new filter modules are called:
Ch1, Ch2, Ch3 and are in filter module 3,9, and 10 of the C1:SUS-MC?_SUSPOS filters. The coherence with these filters is fine. Someone should look into the possibility of simplifying these filters.

It would be good to check for numerical problems in other filters!

  6017   Sat Nov 26 10:55:40 2011 ranaUpdateCDSBeware of fancy filter modules

 

 Could be that what we're seeing is the noise floor of the Direct Form II filter structure (see Matt's 2008 elog) which shows an example (also see G0900928-v1 ).

 

  6030   Mon Nov 28 19:24:51 2011 JenneUpdateCDSBeware of fancy filter modules

[Rana, Jenne]

Some of the funniness is some kind of mysterious interaction between 2 filter modules in the filter banks.  Just FM1 (30:0.0) or just FM4 (Cheby, which is 2 cheby1's) has reasonable coherence.  Both FM1 and FM4 together doesn't do so well - the coherence goes way down.

Just FM1 (30:0.0)

SUSPOS_ETMY_30and0_measured_vs_idealTF.pdf

Just FM4 (Cheby)

SUSPOS_ETMY_Cheby_measured_vs_idealTF.pdf

 Both FM1 and FM4

SUSPOS_ETMY_30and0andCheby_measured_vs_idealTF.pdf

 All the coherences plotted together

SUSPOS_ETMY_30and0andCheby_compareCoherence.pdf

You'd think that the signal encounters FM1, gets filtered, and that result is the signal sent to the next active filter module, FM4, so the 2 filter modules shouldn't interact.  But clearly there's some funny business here since engaging both makes things crappy. 

Matlab investigations to replicate this behavior offline are in progress.

Attachment 4: SUSPOS_ETMY_30and0andCheby_compareCoherence.pdf
SUSPOS_ETMY_30and0andCheby_compareCoherence.pdf
  6031   Mon Nov 28 22:09:24 2011 ranaUpdateCDSBeware of fancy filter modules

To see what might be causing the problem, I used a version of the filter noise test matlab code that Matt had in the elog.

To see if it was a single precision problem, I just recast the input data:   x = single(x)

This is not strictly correct, since some of the rest of the operations are as double precision, but I think that attached plot shows that a casting from double to single is close to the right amount of noise to explain our excess noise problem in the 0.1-1 Hz region.

Den is going to interview Alex to find out if we have some kind of issue like this. My understanding was that all of our filter module calculations were being done in double precision (64 bit), but its possible that some single stuff has crept back in. Currently the FIR filtering code IS single precision and in the past, the SUS code which didn't carry the LSC signals (meaning ASC and damping) were done in single precision.

Attachment 1: noise.pdf
noise.pdf
  11500   Wed Aug 12 16:48:26 2015 IgnacioUpdateIOOBetter? Nope. MISO WIener (T240-X and T240-Y) FF of MCL

Last night, I also worked on a "better" (an improvement, I thought) of the MISO Wiener filter (T240-X and T240-Y witnesses) IIR filter. The FF results are shown below:

Filter:

T240-X

T240-Y

 

Training data + Predicted FIR and IIR subtraction:

Online subtraction results:

MCL
YARM

Subtraction performace:

 Although the predicted FIR and IIR results are "better" than the previous MISO filter, the subtraction performance for this filter is marginally better if not worse (both peak at 15 dB, in slightly different regions). 

Attachment 1: stsx.png
stsx.png
Attachment 2: stsy.png
stsy.png
Attachment 3: performance.png
performance.png
Attachment 4: mcliir.png
mcliir.png
Attachment 5: yarmiir.png
yarmiir.png
Attachment 6: sub.png
sub.png
  11502   Thu Aug 13 12:06:39 2015 Jessica SummaryIOOBetter predicted subtraction did not work as well Online

Yesterday I adjusted the preweighting of my IIR fit to the transfer function of MC2, and also managed to reduce the number of poles and zeros from 8 to 6, giving a smoother rolloff. The bode plots are pictured here:

The predicted IIR subtraction was very close to the predicted FIR subtraction, so I thought these coefficients would lead to a better online filter.

However, the actual subtraction of the MCL was not as good and noise was injected into the Y arm.

The final comparison of the subtraction factors between the online and offline data showed that the preweighting, while it improved the offline subtraction, needs more work to improve the online subtraction also.

Attachment 1: newBodeX.png
newBodeX.png
Attachment 2: newBodeY.png
newBodeY.png
Attachment 3: pred_Sub.png
pred_Sub.png
Attachment 4: MCLSub.png
MCLSub.png
Attachment 5: YarmSub.png
YarmSub.png
Attachment 6: comparison.png
comparison.png
  1237   Mon Jan 19 13:58:53 2009 YoichiUpdateASCBetter ditherServo.pl
Nick Smith (@LHO) tested the ditherServo.pl at Hanford.
He added options to specify exit conditions to the script. Now you can make the script exit when
a condition, such as ArmPower > 1.0, is satisfied, or let it wait until a certain condition is satisfied.

I also modified the script to use ezcastep instead of tdswrite for feedback actuation.
The script now runs ezcastep in the background while the next iteration of the tdsdmd is performed.
Instead of kicking mirrors with a big thrust each time by a single tdswrite command, ezcastep gently moves the mirrors with fine steps.
I also implemented this "background ezcastep" technique in Tobin's tdscntr.pl.

The alignment scripts run smoother now.
  860   Wed Aug 20 12:04:47 2008 JenneUpdateSUSBetter diagonalization of PRM input matrix
The values here should replace those in entry #851 from yesterday.

After checking the results of the input matrix diagonalization, I have determined that Sonia's method (described in LIGO-T070168) is more effective at isolating the eigenmodes than Shihori's method (LIGO-T040054).

So, the actual new PRM input matrices are as follows:

POSPITYAW
UL0.96781.0000.7321
UR1.0000.8025 -0.9993
LR0.7235 -1.1230 -1.0129
LL0.6648 -1.04521.0000


Attached are plots of the spectra of the eigenmodes, using both Shihori's and Sonia's methods. Note that there isn't a good way to get the side peak out of the eigenmodes.

I've put these into the SUS-PRM MEDM screen.
Attachment 1: PRM_Eigmodes_shihori.png
PRM_Eigmodes_shihori.png
Attachment 2: PRM_Eigmodes_sonia.png
PRM_Eigmodes_sonia.png
  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

  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.

  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.

  7957   Tue Jan 29 19:50:49 2013 JenneUpdateLockingBetter POP layout, no extra PRM motion with locked cavity

[Jenne, Jamie, Manasa]

Today's activities focused on getting the POP layout improved, so that we could get clean data for the mode scan measurement. 

As Jamie and Koji pointed out yesterday, the beam was still a little too big on the POP DC PD, and was falling off the diode when the beam moved a small amount.  We have fixed things so that the PD is now at the focus of the lens, and the camera is at a place where the beam takes up most of the area on the TVs.  The beam no longer falls off the PD with cavity fluctuations.  A key point of this work was also to use an extra 2" optic to steer the beam down the length of the POP table, and then do the 50/50 beam splitting later with a 1" optic.  The 1" BS that we had been using (including with the "real" POP beam) is too small.  We could not find a 2" 50/50 BS, so we opted to do the splitting closer to the focal point.  Also, the BS that was splitting the beam between the PD and the camera was a 33% reflector, but now is a 50/50 BS. When we put back the 'real' POP path, we need to consider using larger optics, or a faster lens. The POP path is now good, hopefully for the duration of the half cavity test.

After getting the POP path taken care of, and tweaking up the cavity alignment a little bit, the transmitted power on POP DC is ~22,000 counts, with occasional fluctuations as high as 25,000 counts. 

Jamie looked at the REFL path, and things look sensible there.  The unlocked REFL power is ~36 counts, and the locked power is ~20 counts.  I'm not sure what the 160 counts that Koji mentioned in his edits to elog 7949 is about.

I looked at the PRM oplev with the cavity locked and unlocked, and with today's alignment, there seems to be no difference in the amount of PRM motion when the cavity is locked vs unlocked. 

HalfPRCL_PRM-flatMirror_RefsAreLocked_OthersUnlocked.png

 It still looks like we might be seeing some clipping in the in-vac POP steering mirrors - we haven't gotten to them yet.

Jamie is currently modifying Yuta's mode scan analysis script to look at the data that we have of the cavity.

 


We need more 2" optics.  There are no mounted 2" spares in the various optic "graveyards" (which, PS, we should consolidate all into the cabinet with doors near the optics bench), and the options for boxes in the drawers is slim pickin's.  We have some S-pol stuff, but no Y1s or BS-50s for P-pol.  Since POP, POX, POY, IPANG, TRX and TRY all come out of the vacuum with large beams, we should have some options for these laying around for this kind occasional temporary thing.  We also need to choose, then purchase better 2" lenses for the pickoffs.

Attachment 1: HalfPRCL_PRM-flatMirror_RefsAreLocked_OthersUnlocked.pdf
HalfPRCL_PRM-flatMirror_RefsAreLocked_OthersUnlocked.pdf
  6485   Wed Apr 4 21:43:16 2012 Mike J.UpdateComputersBetter Hysteresis Model

A better hysteresis model based on the simple harmonic oscillator equation. Useless variables have been removed and output can now be saved to workspace for plotting. The model is at "/users/mjenson/matlab/SHO_hyst.mdl".

Attachment 1: SHO_hyst.png
SHO_hyst.png
  15535   Fri Aug 21 15:27:00 2020 gautamUpdateBHDBetter BHD mode-matching

Summary:

The mode-matching between the LO and AS beams is now ~50%. This isn't probably my most average mode-matching in the lab, but I think it's sufficient to start doing some other characterization and we can try squeezing out hopefully another 20-30% by putting the lenses on translation stages, tweaking alignment etc.

Details:

The main change was to increase the optical path length of the IFO AS path, see Attachment #1. This gave me some more room to put a lens and translate it.

  • The LO path uses two lenses, f=200mm and f=100mm to focus the collimator output beam, which is supposedly ~1200um diameter, to something like 400um diameter (measured using beam profiler but not very precisely).
  • This beam is  fairly well collimated, and the beam size is close to what the PMC cavity will want, I opted not to tweak this too much more.
  • For the AS beam, the single bounce reflection from ITMY was used for alignment work.
  • There is a 2" f=600mm lens upstream (not seen in Attachment #1). This supposedly makes a beam with waist ~80um, but I couldn't numerically find a good solution numerically if this assumption is true, so I decided to do the mode-matching empirically.
  • A single f=150mm lens got me a beam that seemed pretty well collimated, and roughly the same size as the LO beam, so I opted to push ahead with that. Later, I measured with the beam profiler that the beam is ~600um in diameter, so the beam isn't very well matched to the LO spot size, but I decided to push ahead nevertheless.
  • Patient alignment work enabled me to see interference fringes.
    • Note that the ITM reflection registers 30 cts (~80 uW). Assuming 800mW transmission through the IMC, I would have expected more like 800mW * 5.637% * 50% * 98.6% * 50% * 10% * 30% * 50% * 50% = 80uW, so this is reasonable I guess. The chain of numbers corresponds to T_PRM * T_BS * R_ITM * R_BS * T_SRM * T_vac_OMC_pickoff * R_in_air_BS * R_homodyneBS.
    • The IFO AS beam appears rather elliptical to the eye (and also on the beam profiler). It already looks like this coming out of the vacuum so not much we can do about it right now I guess. By slightly rotating the f=150mm focusing lens so that the beam going through it at ~10 degrees instead of normal incidence, I was able to get a more circular beam as measured using the beam profiler.
    • With the AS beam blocked, the LO beam registers 240 cts on each DCPD (~0.7 mW). 
    • The expected fringe should then be (sqrt(240) + sqrt(30))^2 - (sqrt(240) - sqrt(30))^2 ~ 440 cts pp.
    • The best alignment I could get is ~200 cts pp, see Attachment #2.

Next steps:

Try the PRMI experiments again, now that I have some confidence that the beams are actually interfering.

See Attachment #3 for the updated spectra - the configuration is PRMI locked with carrier resonant and the homodyne phase is uncontrolled. There is now much better clearance between the electronics noise and the MICH signal as measured in the DCPDs. The "LO only" trace is measured with the PSL shutter closed, so the laser frequency isn't slaved to the IMC length. I wonder why the RIN (seen in the SUM channel) is different whether the laser is locked to the IMC or not? The LO pickoff is before the IMC.

Attachment 1: IMG_7548.JPG
IMG_7548.JPG
Attachment 2: BHD_MM.png
BHD_MM.png
Attachment 3: PRMI_DCPDs.pdf
PRMI_DCPDs.pdf
  14561   Mon Apr 22 21:33:17 2019 JonUpdateSUSBench testing of c1susaux replacement

Today I bench-tested most of the Acromag channels in the replacement c1susaux. I connected a DB37 breakout board to each chassis feedthrough connector in turn and tested channels using a multimeter and calibrated voltage source. Today I got through all the digital output channels and analog input channels. Still remaining are the analog output channels, which I will finish tomorrow.

There have been a few wiring issues found so far, which are noted below.

Channel Type Issue
C1:SUS2-PRM_URVMon Analog input No response
C1:SUS2-PRM_LRVMon Analog input No response
C1:SUS2-BS_UL_ENABLE Digital output Crossed with LR
C1:SUS2-BS_LL_ENABLE Digital output Crossed with UR
C1:SUS2-BS_UR_ENABLE Digital output Crossed with LL
C1:SUS2-BS_LR_ENABLE Digital output Crossed with UL
C1:SUS2-ITMY_SideVMon Analog input Polarity reversed
C1:SUS2-MC2_UR_ENABLE Digital output Crossed with LR
C1:SUS2-MC2_LR_ENABLE Digital output Crossed with UR
     
     

 

  15186   Tue Feb 4 18:13:01 2020 YehonathanUpdatePSLBench testing of PSL ai channels

{Yehonathan, Jon, Jordan}

I tested the ai channels of the new PSL Acromag by looping an already-tested ao channel (C2:PSL-FSS-INOFFSET) back to the different ai channels.

I use Jon's IFOTest with /users/jon/ifotest/PSL.yaml.

I created a spreadsheet for the testing based on the current wiring spreadsheet. I added two columns for the high and low readings for each ai channel (attached pdf).

I marked in red the failed channels. Some of them are probably calibration issues, but the ones that show the same voltage for high and low are probably disconnected wires.

I redid the test on the channel that seemed disconnected to confirm.

I created a yaml file with all the failed channels for retesting called /users/jon/ifotest/PSL_failed_channels.yaml.

Attachment 1: c1psl_wire_testing_-_By_Connector.pdf
c1psl_wire_testing_-_By_Connector.pdf c1psl_wire_testing_-_By_Connector.pdf c1psl_wire_testing_-_By_Connector.pdf c1psl_wire_testing_-_By_Connector.pdf
  15187   Wed Feb 5 08:57:11 2020 YehonathanUpdatePSLBench testing of PSL ai channels

I checked the failed channels against the EPICS database definitions and the yaml file inputted to IFOTest. The channels where the readings are something other than +10/0 V, but the high/low values do change, I think can be attributed to one of two things:

  • An incorrect gain and/or offset conversion parameter in the yaml file
  • The EPICS SMOO parameter (smoothing) is set to some long value

I fixed the channel gains/offsets in the master yaml file (PSL.yaml). I also disabled smoothing in the EPICS defintions of the new PSL channels for the purpose of testing. We can uncomment those lines after installing the new chassis if noise is a problem. Please go ahead and re-test the channels again.

Quote:

I marked in red the failed channels. Some of them are probably calibration issues, but the ones that show the same voltage for high and low are probably disconnected wires.

  15189   Wed Feb 5 21:04:10 2020 YehonathanUpdatePSLBench testing of PSL ai channels

{Yehonathan, Jon}

We retested the failed ai channels. Most of them got fixed by applying the inverse calibration in the yaml file.

We still find some anomalous channels, mostly in the DB25 connector. Turns out, their limits were ill-defined in the EPICS database. Specifying the right limit fixed the issue.

We find one miswired channel (BNC4). We connected the BNC to the right channel on the Acromag unit which fixed the issue.

Overall all the ai channels were successfully bench-tested.

Quote:

I checked the failed channels against the EPICS database definitions and the yaml file inputted to IFOTest. The channels where the readings are something other than +10/0 V, but the high/low values do change, I think can be attributed to one of two things:

  • An incorrect gain and/or offset conversion parameter in the yaml file
  • The EPICS SMOO parameter (smoothing) is set to some long value

I fixed the channel gains/offsets in the master yaml file (PSL.yaml). I also disabled smoothing in the EPICS defintions of the new PSL channels for the purpose of testing. We can uncomment those lines after installing the new chassis if noise is a problem. Please go ahead and re-test the channels again.

Quote:

I marked in red the failed channels. Some of them are probably calibration issues, but the ones that show the same voltage for high and low are probably disconnected wires.

  14840   Sun Aug 11 11:47:42 2019 gautamUpdateCDSBench test of c1iscaux

I bench tested the functionality of all the c1iscaux Acromag crate channels. Summary: we are not ready for a Monday install, much debugging remains.

  1. DAC channels were tested using 4 ch oscilloscope and stepping the whitening gain sliders through their 15 gain settings
    • Response was satisfactory - the output changes between 0 - 5 V DC in 15 steps.
    • This analog voltage is converted to binary representation by an on-board ADC on the whitening boards. So we may have to tune the offset voltage and range to avoid accidental bit flipping due to the analog voltage of a particualr step falling close to the bit-flipping edge of the on-board ADC. This will require an in-situ test.
    • Test passed
  2. BIO output channels were tested using a DMM, and monitoring the resistance between the BIO pin and the RTN pin. In the "ON" state, the expected resistance is ~5 Mohm, and in the off state, it is ~3 ohms.
    • The AA filter switches on BIO1 unit do not show the expected behavior - @ Chub, please check the wiring.
    • All others (except the mbboDirect bits, see next bullet) were okay, including those for the CM board that are NOT part of the mbboDirect groups.
    • Test failed
  3. ADC channels were tested by driving a ~2Vpp 300mHz sine wave with a function generator, and looking at the corresponding EPICS channel with StripTool.
    • I found that all the ADC channels don't function as expected.
    • Part of the problem is due to incorrect formatting of the EPICS records in the db files, but I think the ADCs also need to be calibrated with the precision voltage source.
    • Why only ADCs require calibration and not the DACs????
    • Test failed
  4. mbboDirect BIO output test - I made a little LED breadboard tester kit to simultaneously monitor the status of these groups of binary outputs.
    • The LSB is toggled as expected when moving the gain slider along.
    • However, the other bits in the group are not toggled correctly.
    • I believe this is a problem with either (i) the way the EPICS record is configured to address the bits or (ii) the incorrect modbus datatype is used to initialize the ioc.
    • It will be helpful if someone can look into this and get the mbboDirect bits working, I don't really want to spend more time on this.
    • Test failed

I am leaving the crate powered (by bench supplies) in the office area so I have the option to work remotely on this.

  1275   Thu Feb 5 16:21:07 2009 JenneFrogsComputersBelladonna connects to the wireless Martian network again

Symptoms:  Belladonna could not (for a while) connect to the wireless network, since there was a driver problem for the wireless card.  This (I believe) started when Yoichi was doing updates on it a while back.

The system: Belladonna is a Dell Inspirion E1505 laptop, with a Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01)

Result:  Belladonna now can talk to it's wireless card, and is connected to the Martian network.  (MEDM and Dataviewer both work, so it must be on the network.)

 

What I did:

0.  Find a linux forum with the following method:  http://www.thelinuxpimp.com/main/index.php?name=News&file=article&sid=749

The person who wrote this has the exact same laptop, with the same wireless card.

1.  Get a new(er) version of ndiswrapper, which "translates" the Windows Driver for the wireless card to Linux-ese.  Belladonna previously was using ndiswrapper-1.37.

$wget http://nchc.dl.sourceforge.net/sourceforge/ndiswrapper/ndiswrapper-1.42.tar.gz

2.  Put the ndiswrapper in /home/controls/Drivers, and installed it.

$ndiswrapper -i bcmwl5.inf  3.  Get and put the Windows driver in /home/controls/Drivers/WiFi

$wget http://ftp.us.dell.com/network/R140747.EXE
4. Unzip the driver $unzip -a R140747.EXE

5.  Make Fedora use ndiswrapper

$ndiswrapper -m

$modprobe ndiswrapper

6. Change some files to make everything work:

/etc/sysconfig/wpa_supplicant      CHANGE FROM: DRIVERS="-Dndiswrapper"     CHANGE TO: DRIVERS="-Dwext"

/etc/sysconfig/network-scripts/ifcfg-wlan0      CHANGE FROM: BOOTPROTO=none      CHANGE TO: BOOTPROTO=dhcp

/etc/rc.d/init.d/wpa_supplicant        CHANGE FROM: daemon $prog -c $conf $INTERFACES $DRIVERS -B        CHANGE TO: daemon $prog -c$conf $INTERFACES $DRIVERS -B

6.  Restart things

$service wpa_supplicant restart
$service network restart

7.  Restart computer (since it wasn't working after 1-6, so give a restart a try)

8. Success!!!  MEDM and Dataviewer work without any wired internet connection => wireless card is all good again!

ELOG V3.1.3-