40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 75 of 330  Not logged in ELOG logo
ID Date Author Type Category Subject
  12874   Wed Mar 8 18:18:51 2017 johannesUpdateComputer Scripts / Programsloss script

I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.

  12873   Wed Mar 8 15:28:37 2017 SteveUpdateOptical Leversoplev laser RIN

Gautam and Steve,

Quote:

Corrected oplev laser RIN plot at day 3

RXA:

  1. to measure RIN, the lever arm should be really short, not long.
  2. the beam should be 3x smaller than the active area of the diode
  3. the specular beam should be dumped on a razor dump.
  4. we need to make a summary page for HeNe laser testing so that we can see 24 hour specgrams of these things for ~3-4 lasers at the same time.
  5. We should add specgram stuff for the existing HeNe SUM channels on the active OLs.

GV: The channel the PD Steve is using is hooked up to C1:ALS-FC_X_F_IN. As I found out today, there can be considerable RF pickup between the C1:ALS-FC_X_F_IN and C1:ALS-FC_Y_F_IN channels, which share a common 4-pin LEMO cable - this is because the rise time of the square wave output of the Wenzel dividers is <1us, so suitability of this particular channel for the RIN measurement set up has to be reconsidered. Perhaps we can use one of the six spare PEM channels over at 1X6. 

We did the following:

1, switched data channel  from  C1:ALS-FC_X_F_IN to C1:PEM-MIC_1_OUT_DQ   Actual connection at 1X7 rack, input C17

    Tested channel with 1Hz, 100 mV sine wave through DV

2, placed BS into the beam path so the reflected value on the PDA100A 0.1mW,  beam od ~1mm, beam path lenght 11 cm, gain 20dB 3.7Vdc

    The full output of this 1103P 2.8 mW was saturating the PDA100A

Summery :finding it to be too good to be this good

Attachment 1: RIN.jpg
RIN.jpg
Attachment 2: RIN_1103P_rotated.pdf
RIN_1103P_rotated.pdf
  12872   Tue Mar 7 15:17:19 2017 SteveBureaucracyGeneralproperty tag

Property tag found.

Attachment 1: property_tag.jpg
property_tag.jpg
  12871   Mon Mar 6 16:32:36 2017 SteveUpdateGeneralold NPRO

16 years old Lightwave NPRO M126-1064-700, sn 415 power output is tripping continously to zero.

The Lightwave Controller 125/126-OPN-POS sn516 was used in this test. Settings were lowered to close to nominal values without any success.

One can not determine what is broken: head or controller. This NPRO head was under Manasa's desk.
 

  12870   Mon Mar 6 14:47:49 2017 gautamUpdateSummary PagesCode status check script modified

For a few days now, the "code status" page has been telling us that the summary pages are DEAD, even though the pages themselves seemed to be generating plots. I logged into the 40m shared account on the cluster and checked the status of the condor job (with condor_q), and did not find anything odd there. I decided to consult Max, who pointed out that the script that checks the code status (/home/40m/DetectorChar/bin/checkstatus) was looking for a particular string in the log files ("gw_daily_summary"), while the recent change in the default output of condor_q meant that the string actually being written to the log files was "gw_daily_summa". This script has now been modified to look for instances of "gw_daily" instead, and so the code status indicator seems to be working again...

The execution of the summary page scripts has also been moved back to pcdev1 (from pcdev2, where it was moved to temporarily because of some technical problems with pcdev1).

  12869   Mon Mar 6 12:34:30 2017 johannesSummaryASSASS light injection scenarios

What we want from the light source for the AS port light injection:

  • Frequency control for locking and maintaining known offset from arm cavity resonances -> see below
  • Fast extinguishing light in the IFO -> AOM first order switching

We have four possible laser sources that we can use for the injection of 1064 nm from the back:

  • There are ~65 mW of IR power coming from the PSL doubling oven, of which ~2mW are used for the fiber beat box. The remaining light is currently dumped on the PSL table and would be available. It is picked off after the PMC and does not have any of the sidebands.
  • There is a ~200 mW Lightwave NPRO on the PSL table that is currently unused.
  • Koji said he has a ~500mW NPRO in the OMC lab that has no PZT actuation. I contacted a couple companies about fiber-coupled variable AOM frequency shifters that we can pair with this laser.
  • I don't think using the high power beam of the PSL itself is a good idea, especially if we want to map the loss on the optics, because' we'll need it for the dither locking

I think for maximum flexibility it's best to fiber-couple whichever source we choose on the PSL table and then just collimate it out of a fiber on the AS table. This way if we want to add fiber-coupled modulators of any kind it's a plug-and-play modification.

Different frequency control schemes are:

  • Modulate sidebands on the light and stabilize directly to the arm, using POX/Y or back-reflection at AS
    • Free-space resonant EOM
    • Free-space broadband EOM with Rich's resonant amplifier attachment
    • Fiber-coupled EOM
  • Offset phaselock:
    • PSL IR: Transfer mode-cleaner stability
      • Can lock arms while measurement in progress, but will have PSL IR light on PDs
    • Green from the end;
      • Broadly tunable laser frequency and no interference from IR.

Either way we'll need a few things:

  • Faraday Isolator
    • required for PDH locking, optional if we phaselock instead
  • AOM
    • We have free-space available, looking into fiber-coupled ones with frequency tuning
    • Fast switching electronics
  • Various fiber stuff
    • We have enough to set up the fiber coupling of one light source. I'm starting with the 200 mW NPRO but this is technically interchangable.

I'm working on how to best set this up at the AS port and interfere with normal operation as little as possible. Ideally we use a Faraday just like for squeezed light injection, but this requires some modification of the layout, although nothing that involves mode-matching.

 

 

  12868   Mon Mar 6 09:12:59 2017 SteveUpdatesafety crane inspection 2017

All 3 cranes inspected by professional Fred Goodbar of Konecranes and load tested with 450 lbs at max reach on Friday, March 3, 2017

 

 

Attachment 1: inspection_2017.jpg
inspection_2017.jpg
  12867   Sun Mar 5 12:41:23 2017 gautamUpdateIMCWFS servo-steppin

I've been sitting on some data for a while now which I finally got around to plotting. Here is a quick summary:

Attachment #1: I applied a step input to the offset of each of the six WFS loops and observed the step response. The 1/e time constant for all 4 WFS loops is <10s suggesting a bandwidth a little above 0.1Hz. However, the MC2 P and Y loops have a much longer time contant of ~150s. Moreover, it looks like the DC centering of the spot on the QPD isn't great - the upper two quadrants (as per the MEDM screen) have ~3x the cts of the lower pair.
I did not (yet) try increasing the gain of this loop to see if this could be mitigated. I accidentally saved this as a png, I will put up the pdf plot

Attachment #2: This is a comparison of the WFS error signals with the loops engaged (solid lines) vs disabled (dashed lines). Though these measurements were taken at slightly different times, they are consistent with the WFS loop bandwidths being ~0.1Hz.

Attachment #3: Comparison of the spectra of the testpoint channels and their DQ counterparts at the same time which are sampled at 512Hz. It does not look like there is any dramatic aliasing going on, although it is hard to tell what exactly is the order of the digital AA filter implemented by the RCG. Further investigation remains to be done... For reference, here are some notes: T1600059, T1400719

GV 7 March 2017 6pm: It looks like we use RCG v2.9.6, so it should be the latter document that is applicable. I've been going through some directories to try and find the actual C-code where the filter coeffs are defined, but have been unsuccessful so far...

Quote:

I will update with the in-loop error signal spectra, which should give us some idea of the loop bandwidth.


I will look into lowering the sampling rate, and how much out-of-band power is aliasing into the 0-256 Hz band and update with my findings.

 

Attachment 1: WFS_stepping.png
WFS_stepping.png
Attachment 2: WFS_comparisons.pdf
WFS_comparisons.pdf WFS_comparisons.pdf
Attachment 3: WFSdigitalAA.pdf
WFSdigitalAA.pdf WFSdigitalAA.pdf
  12866   Fri Mar 3 17:24:21 2017 SteveUpdateOptical Leversoplev laser RIN

Corrected oplev laser RIN plot at day 3

RXA:

  1. to measure RIN, the lever arm should be really short, not long.
  2. the beam should be 3x smaller than the active area of the diode
  3. the specular beam should be dumped on a razor dump.
  4. we need to make a summary page for HeNe laser testing so that we can see 24 hour specgrams of these things for ~3-4 lasers at the same time.
  5. We should add specgram stuff for the existing HeNe SUM channels on the active OLs.

GV: The channel the PD Steve is using is hooked up to C1:ALS-FC_X_F_IN. As I found out today, there can be considerable RF pickup between the C1:ALS-FC_X_F_IN and C1:ALS-FC_Y_F_IN channels, which share a common 4-pin LEMO cable - this is because the rise time of the square wave output of the Wenzel dividers is <1us, so suitability of this particular channel for the RIN measurement set up has to be reconsidered. Perhaps we can use one of the six spare PEM channels over at 1X6. 

Attachment 1: 3march17.pdf
3march17.pdf
  12865   Thu Mar 2 20:32:18 2017 LydiaUpdateIMCFront panel for 29.5 MHz amplifier box

[gautam, lydia]

I pulled out the box and found the problem: the +24 V input to the amplifier was soldered messily and shorted to ground. So I resoldered it and tested the box on the bench (drove with Marconi and checked that the gain was correct on scope). This also blew the fuse where the +24 power is distributed, so I replaced it. The box is reinstalled and the mode cleaner is locking again with the WFS turned on.

Since I tried to keep the cable lengths the same, the demod phases shouldn't have changed significantly since the amplifier was first installed. Gautam and I checked this on a scope and made sure the PDH signals were all in the I quadrature. In the I vs. Q plot, we did also see large loops presumably corresponding to higher order mode flashes.

Quote:

Walking over to the 1X1, I noticed that the +24V Sorensen that should be pushing 2.9A of current when our new 29.5MHz amplifier is running, was displaying 2.4A. This suggests the amplifier is not being powered. I toggled the power switch at the back and noticed no difference in either the MC locking behaviour or the current draw from the Sorensen.

 

 

  12864   Thu Mar 2 17:58:45 2017 ranaUpdateOptical Leversoplev laser RIN

This measurement looks bogus - the difference between dark and not dark is not significant enough to believe. Need to figure out how to match better into the ADC range.

  12863   Thu Mar 2 13:59:04 2017 SteveUpdateOptical Leversoplev laser RIN

The laser got much better at low frequency as it warmed up. This laser is almost as good as the electronics?

Dark noise cal was the same today as it was 2 days ago.

 

Attachment 1: 1103P@2d.png
1103P@2d.png
  12862   Wed Mar 1 23:56:09 2017 gautamUpdateIMCFront panel for 29.5 MHz amplifier box

The alignment wasn't disturbed for the photo-taking - I just re-checked that the spot is indeed incident on the MC REFL PD. MC REFL appeared dark because I had placed a physical beam block in the path to avoid accidental PSL shutter opening to send a high power beam during the photo-taking. I removed this beam block, but MC wouldn't lock. I double checked the alignment onto the MC REFL PD, and verified that it was ok.

Walking over to the 1X1, I noticed that the +24V Sorensen that should be pushing 2.9A of current when our new 29.5MHz amplifier is running, was displaying 2.4A. This suggests the amplifier is not being powered. I toggled the power switch at the back and noticed no difference in either the MC locking behaviour or the current draw from the Sorensen.

To avoid driving a possibly un-powered RF amplifier, I turned off the Marconi and the 29.5MHz source. I can't debug this anymore tonight so I'm leaving things in this state so that Lydia can check that her box works fine...

Quote:

I turned the RF sources back on and opened the PSL shutter. MC REFL was dark on the camera; people were taking pictures of the PD face today so I assume it just needs to be realigned before the mode cleaner can be locked again. 

 

  12861   Wed Mar 1 21:15:40 2017 LydiaUpdateIMCFront panel for 29.5 MHz amplifier box


I installed the front panel today. While I had the box out I also replaced the fast decoupling capacitor witha 0.1 uF ceramic one. I made SMA cables to connect to the feedthroughs and amplifier, trying to keep the total lengths as close as possible to the cables that were there before to avoid destroying the demod phases Gautam had found. I didn't put in indicator lights in the interest of getting the mode cleaner operational again ASAP. 

I turned the RF sources back on and opened the PSL shutter. MC REFL was dark on the camera; people were taking pictures of the PD face today so I assume it just needs to be realigned before the mode cleaner can be locked again. 

I've attached a schematic for what's in the box, and labeled the box with a reference to this elog. 

Attachment 1: RF_amp_(1).pdf
RF_amp_(1).pdf
  12860   Wed Mar 1 17:25:28 2017 SteveUpdateLSCMCREFL condition pictures

Gautam and Steve,

 

Our MCREFL rfpd C30642GH 2x2mm beeing investigated for burned spots.

Atm1,           unused -  brand new pd

Atm2,3,4       MCREFL in place was not moved

More pictures will be posted on 40m Picassa site later. 

 

Attachment 1: IMG_3646.JPG
IMG_3646.JPG
Attachment 2: mcRefl_1.jpg
mcRefl_1.jpg
Attachment 3: mcRefl_3.jpg
mcRefl_3.jpg
Attachment 4: mcRefl_5.jpg
mcRefl_5.jpg
  12859   Wed Mar 1 16:00:41 2017 gautamUpdateComputer Scripts / ProgramsMatlab R2016b installed

Since it would be nice to have the latest version of Matlab, with all its swanky new features (?), available on the control room computers and Optimus, I downloaded Matlab R2016b and activated it with the Caltech Campus license. I installed it into /cvs/cds/caltech/apps/linux64/matlab16b. Specifically, I would like to run the coating optimization code on Optimus, where I can try giving it more stringent convergence criterion to see if it converges to a better spot.

I trust that this way, we don't interfere with any of the rtcds stuff.

If I've done something illegal license-wise or if this is likely to cause havoc, please point me to what is the correct way to do this.

GV 18 Mar 2017: Though I installed this using the campus network license key, this seems to only work on Rossa. If I run it on the other control room machines/Optimus, it throws up a licensing error. I will check with Larry W. as to how to resolve this...

 

  12858   Wed Mar 1 08:28:04 2017 SteveUpdateOptical Leversoplev laser RIN

Gautam and Steve,

New JDSU 1103P HeNe oplev laser RIN was measured on the SP table with cover on.

This is the beginning of an effort to improve oplev laser noise.

 

Attachment 1: RIN_1103P.png
RIN_1103P.png
Attachment 2: RIN_HeNe.png
RIN_HeNe.png
  12857   Tue Feb 28 21:05:44 2017 ranaSummaryIOOMC Length offset changes MCWFS offsets

The input offset on the MC length servo board changes the lock point of the length loop (by how much? need to calibrate this slider into meters & Hz).

The SUM signal on the MC WFS is ~few 1000. This is several times larger than the pit/yaw signals. This is bad. it means that the TEM00 mode on the WFS (or what the WFS interperets as a TEM00) is larger than the TEM01/10 that its supposed to measure.

So if the beam moves on the WFS head it will convert this large common mode signal into a differential one.

We moved the MC Servo offset around from -3 to +3 V today and saw that it does affect the transmitted light level, but we need to think more to see how to put the offset at the real center of the resonance. This is complicated by the fact that the MCWFS loops seem to have some several minutes time constant so things are essentially always drifting.

  1. Characterize and juice up the WFS loops.
  2. Figure out how to set the MC length loop offset. Is this bad offset changing the zero point of the MC WFS loops?
  3. If so, it may be a source of excess jitter noise in the interferometer.

I changed the McREFL SMOO to make it easier to use this noisy channel to diagnose small alignment changes:

caput C1:IOO-MC_RFPD_DCMON.SMOO 0.1

  12856   Tue Feb 28 18:25:22 2017 ranaUpdatePEMETMX damping recovered

Huh? So should we ask them to put the container back? Or do you have some other theory about ETMX tripping that is not garbage related?

Quote:

ETMX sus damping recovered.

Note: The giant metal garbage container was moved from the south west corner of CES months ago.

 

  12855   Tue Feb 28 08:04:48 2017 steveUpdatePEMETMX damping recovered

ETMX sus damping recovered.

Note: The giant metal garbage container was moved from the south west corner of CES months ago.

Quote:

ETMX sus damping recovered.  PSL enclousure is dusty at 20V rotation speed. Rainy days as outside condition.

 

 

Attachment 1: ETMX.png
ETMX.png
  12854   Tue Feb 28 01:28:52 2017 johannesUpdateComputersc1psl un-bootable

It turned out the 'ringing' was caused by the respective other ETM still being aligned. For these reflection measurements both test masses of the other arm need to be misaligned. For the ETM it's sufficient to use the Misalign button in the medm screens, while the ITM has to be manually misaligned to move the reflected beam off the PD.

I did another round of armloss measurements today. I encountered some problems along the way

  • Some time today (around 6pm) most of the front end models had crashed and needed to be restarted GV: actually it was only the models on c1lsc that had crashed. I noticed this on Friday too.
  • ETMX keeps getting kicked up seemingly randomly. However, it settles fast into it's original position.

General Stuff:

  • Oscilloscope should sample both MC power (from MC2 transmitted beam) and AS signal
  • Channel data can only be loaded from the scope one channel at a time, so 'stop' scope acquisition and then grab the relevant channels individually
  • Averaging needs to be restarted everytime the mirrors are moved triggering stop and run remotely via the http interface scripts does this.

Procedure:

  1.     Run LSC Offsets
  2.     With the PSL shutter closed measure scope channel dark offsets, then open shutter
  3.     Align all four test masses with dithering to make sure the IFO alignment is in a known state
  4.     Pick an arm to measure
  5.     Turn the other arm's dither alignment off
  6.     'Misalign' that arm's ETM using medm screen button
  7.     Misalign that arm's ITM manually after disabling its OpLev servos looking at the AS port camera and make sure it doesn't hit the PD anymore.
  8.     Disable dithering for primary arm
  9.     Record MC and AS time series from (paused) scope
  10.     Misalign primary ETM
  11.     Repeat scope data recording

Each pair of readings gives the reflected power at the AS port normalized to the IMC stored power:

\widehat{P}=\frac{P_{AS}-\overline{P}_{AS}^\mathrm{dark}}{P_{MC}-\overline{P}_{MC}^\mathrm{dark}}

which is then averaged. The loss is calculated from the ratio of reflected power in the locked (L) vs misaligned (M) state from

\mathcal{L}=\frac{T_1}{4\gamma}\left[1-\frac{\overline{\widehat{P}_L}}{\overline{\widehat{P}_M}} +T_1\right ]-T_2

Acquiring data this way yielded P_L/P_M=1.00507 +/- 0.00087 for the X arm and P_L/P_M=1.00753 +/- 0.00095 for the Y arm. With \gamma_x=0.832 and \gamma_x=0.875 (from m1=0.179, m2=0.226 and 91.2% and 86.7% mode matching in X and Y arm, respectively) this yields round trip losses of:

\mathcal{L}_X=21\pm4\,\mathrm{ppm}  and  \mathcal{L}_Y=13\pm4\,\mathrm{ppm}, which is assuming a generalized 1% error in test mass transmissivities and modulation indices. As we discussed, this seems a little too good to be true, but at least the numbers are not negative.

  12853   Mon Feb 27 15:33:10 2017 SteveUpdateVACRGA scan at day 130

Valve configuration: vacuum normal

Vacuum envelope: 23.5 C

RGA head: 46.6 C

 

Attachment 1: rgascan@130d.png
rgascan@130d.png
  12852   Fri Feb 24 20:38:01 2017 johannesUpdateComputersc1psl boot-stall culprit identified

[Gautam, Johannes]

c1psl finally booted up again, PMC and IMC are locked.

Trying to identify the hickup from the source code was fruitless. However, since the PMCTRANSPD channel acqusition failure occured long before the actual slow machine crashed, and since the hickup in the boot seemed to indicate a problem with daughter module identification, we started removing the DIO and DAQ modules:

  1. Started with the ones whose fail LED stayed lit during the boot process: the DIN (XVME-212) and the three DACs (VMIVME4113). No change.
  2. Also removed the DOUT (XVME-220) and the two ADCs (VMIVME 3113A and VMIVME3123). It boots just fine and can be telnetted into!
  3. Pushed the DIN and the DACs back in. Still boots.
  4. Pushed only VMIVME3123 back in. Boot stalls again.
  5. Removed VMIVME3123, pushed VMIVME 3113A back in. Boots successfully.
  6. Left VMIVME3123 loose in the crate without electrical contact for now.
  7. Proceeded to lock PMC and IMC

The particle counter channel should be working again.

  • VMIVME3123 is a 16-Bit High-Throughput Analog Input Board, 16 Channels with Simultaneous Sample-and-Hold Inputs
  • VMIVME3113A is a Scanning 12-Bit Analog-to-Digital Converter Module with 64 channels

/cvs/cds/caltech/target/c1psl/psl.db lists the following channels for VMIVME3123:

Channels currently in use (and therefore not available in the medm screens):

  • C1:PSL-FSS_SLOW_MON
  • C1:PSL-PMC_PMCERR
  • C1:PSL-FSS_SLOWM
  • C1:PSL-FSS_MIXERM
  • C1:PSL-FSS_RMTEMP
  • C1:PSL-PMC_PMCTRANSPD

Channels not currently in use (?):

  • C1:PSL-FSS_MINCOMEAS
  • C1:PSL-FSS_RCTRANSPD
  • C1:PSL-126MOPA_126MON
  • C1:PSL-126MOPA_AMPMON
  • C1:PSL-FSS_TIDALINPUT
  • C1:PSL-FSS_TIDALSET
  • C1:PSL-FSS_RCTEMP
  • C1:PSL-PPKTP_TEMP

There are plenty of channels available on the asynchronous ADC, so we could wire the relevant ones there if we done care about the 16 bit synchronous sampling (required for proper functionality?)

Alternatively, we could prioritize the Acromag upgrade on c1psl (DAQ would still be asynchronous, though). The PCBs are coming in next Monday and the front panels on Tuesday.

 

 

Some more info that might come in handy to someone someday:

The (nameless?) Windows 7 laptop that lives near MC2 and is used for the USB microscope was used for interfacing with c1psl. No special drivers were necessary to use the USB to RS232 adapter, and the RJ45 end of the grey homemade DB9 to RJ45 cable was plugged into the top port which is labeled "console 1". I downloaded the program "CoolTerm" from http://freeware.the-meiers.org/#CoolTerm, which is a serial protocol emulator, and it worked out of the box with the adapter. The standard settings fine worked for communicating with c1psl, only a small modification was necessary: in Options>Terminal make sure that "Enter Key Emulation" is set from "CR+LF" to "CR", otherwise each time 'Enter' is pressed it is actually sent twice.

  12851   Thu Feb 23 19:44:48 2017 johannesUpdateComputersc1psl un-bootable

Yes, that was one of the things that I wanted to look into. One thing Gautam and I did that I didn't mention was to reconnect the SRM satellite box and move the optic around a bit, which didn't change anything. Once the c1psl problem is fixed we'll resume with that.

Quote:

The fringes seen on the oscope are mostly likely due to the interference from multiple light beams. If there are laser beams hitting mirrors which are moving, the resultant interference signal could be modulated at several Hertz, if, for example, one of the mirrors had its local damping disabled.

 

Speaking of which:

Using one of the grey RJ45 to D-Sub cables with an RS232 to USB adapter I was able to capture the startup log of c1psl (using the usb camera windows laptop). I also logged the startup of the "healthy" c1aux, both are attached. c1psl stalls at a point were c1aux starts testing for present vme modules and doesn't continue, however is not strictly hung up, as it still registers to the logger when external login attempts via telnet occur. The telnet client simply reports that the "shell is locked" and exits. It is possible that one of the daughter cards causes this. This seems to happen after iocInit is called by the startup script at /cvs/cds/caltech/target/c1psl/startup.cmd, as it never gets to the next item "coreRelease()". Gautam and I were trying to find out what happends inside iocInit, but it's not clear to us at this point from where it is even called. iocInit.c and compiled binaries exist in several places on the shared drive. However, all belong to R3.14.x epics releases, while the logfile states that the R3.12.2 epics core is used when iocInit is called.

Next we'll interrupt the autoboot procedure and try to work with the machine directly.

Attachment 1: slow_startup_logs.tar.gz
  12850   Thu Feb 23 18:52:53 2017 ranaUpdateComputersc1psl un-bootable

The fringes seen on the oscope are mostly likely due to the interference from multiple light beams. If there are laser beams hitting mirrors which are moving, the resultant interference signal could be modulated at several Hertz, if, for example, one of the mirrors had its local damping disabled.

  12849   Thu Feb 23 15:48:43 2017 johannesUpdateComputersc1psl un-bootable

Using the PDA520 detector on the AS port I tried to get some better estimates for the round-trip loss in both arms. While setting up the measurement I noticed some strange output on the scope I'm using to measure the amount of reflected light.

The interferometer was aligned using the dither scripts for both arms. Then, ITMY was majorly misaligned in pitch AND yaw such that the PD reading did not change anymore. Thus, only light reflected from the XARM was incident of the AS PD. The scope was showing strange oscillations (Channel 2 is the AS PD signal):

For the measurement we compare the DC level of the reflection with the ETM aligned (and the arm locked) vs a misaligned ETM (only ITM reflection). This ringing could be observed in both states, and was qualitatively reproducible with the other arm. It did not show up in the MC or ARM transmission. I found that changing the pitch of the 'active' ITM (=of the arm under investigation) either way by just a couple of ticks made it go away and settle roughly at the lower bound of the oscillation:

In this configuration the PD output follows the mode cleaner transmission (Channel 3 in the screen caps) quite well, but we can't take the differential measurement like this, because it is impossible to align and lock the arm but them misalign the ITM. Moving the respective other ITM for potential secondary beams did not seem to have an obvious effect, although I do suspect a ghost/secondary beam to be the culprit for this. I moved the PDA520 on the optical table but didn't see a change in the ringing amplitude. I do need to check the PD reflection though.

Obviously it will be hard to determine the arm loss this way, but for now I used the averaging function of the scope to get rid of the ringing. What this gave me was:
(16 +/- 9) ppm losses in the x-arm and (-18+/-8) ppm losses in the y-arm

The negative loss obviously makes little sense, and even the x-arm number seems a little too low to be true. I strongly suspect the ringing is responsible and wanted to investigate this further today, but a problem with c1psl came up that shut down all work on this until it is fixed:

I found the PMC unlocked this morning and c1psl (amongst other slow machines) was unresponsive, so I power-cycled them. All except c1psl came back to normal operation. The PMC transmission, as recorded by c1psl,  shows that it has been down for several days:

Repeated attempts to reset and/or power-cycle it by Gautam and myself could not bring it back. The fail indicator LED of a single daughter card (the DOUT XVME-212) turns off after reboot, all others stay lit. The sysfail LED on the crate is also on, but according to elog 10015 this is 'normal'. I'm following up that post's elog tree to monitor the startup of c1psl through its system console via a serial connection to find out what is wrong.

  12848   Thu Feb 23 14:50:26 2017 SteveUpdateGeneral USB microscope returned

The microscope shipped back to the vendor for credit yesterday.

Quote:

http://www.amscope.com/3-5x-180x-boom-stand-trinocular-zoom-stereo-microscope-with-144-led-ring-light-and-10mp-camera.html will be ordered today.

The actual unit we are getting has lockable zoom for better repeatability after calibration: SM-3NTPZZ-144

Quote: CWQ6-020817

 

 

 

  12847   Thu Feb 23 10:59:53 2017 gautamUpdateCOCRC folding mirrors - coating optimization

I've now made a DCC page for the mirror specifications, all revisions should be reflected there.

Over the last couple of days, I've been playing around with Rana's coating optimization code to come up with a coating design that will work for us. The basic idea is a to use MATLAB's particle swarm constrained optimization tool to minimize an error function that is a composite of four penalties:

  1. Thermal noise - we use the proxy function from E0900068-v3 to do this
  2. Deviation from target T @1064nm, p-pol
  3. Deviation from target T @532nm, p and s-pol
  4. HR Surface field

On the AR side, I only considered 2 and 3. The weighting of these four components were set somewhat arbitrarily, but I seem to be able to get reasonable results so I am going with this for now. 

From my first pass at it, the numbers I've been able to get, for 19 layer pairs, are (along with some plots):

HR Side:

  • T = 50ppm, 1064nm p-pol
  • T = 99%, 532nm s and p-pol

       (in this picture, the substrate is to the right of layer 38)

AR Side:

  • R ~50ppm for 532nm, s and p-pol

   (substrate to the right of layer 38)

These numbers are already matching the specs we have on the DCC page currently. I am not sure how much better we can get the specs on the HR side keeping with 19 layer pairs... 

All of this data, plus the code used to generate them, is on the gitlab coatings page...

 

Attachment 1: PR3_R_170222_2006.pdf
PR3_R_170222_2006.pdf
Attachment 2: PR3_123_TOnoise_170222_2203.pdf
PR3_123_TOnoise_170222_2203.pdf
Attachment 3: PR3_123_Layers_170222_2203.pdf
PR3_123_Layers_170222_2203.pdf
Attachment 4: PR3AR_R_170222_2258.pdf
PR3AR_R_170222_2258.pdf
Attachment 5: PR3AR_123_Layers_170222_2258.pdf
PR3AR_123_Layers_170222_2258.pdf
  12846   Thu Feb 23 09:32:20 2017 KojiUpdateSUS wire standoffs update

Kyle took high quality images of  the three sapphire prisms using the microscope @Downs. He analyzed the images to see the radius of the groove.

They all look sufficiently sharp for a 46um steel wire. Thumbs up.
I am curious to see how the wire Q is with grooved sapphires, ungrooved sapphires, grooved ruby, grooved aluminum stand off, and so on.

Attachment 1: Sapphire_prism_1(A015).png
Sapphire_prism_1(A015).png
Attachment 2: Sapphire_prism_2(A016).png
Sapphire_prism_2(A016).png
Attachment 3: Sapphire_prism_3(A014).png
Sapphire_prism_3(A014).png
  12845   Wed Feb 22 10:16:54 2017 ranaSummaryGeneralAlternative Calibration Scheme

OK, but the questions still stands: "Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?"

Quote:

We get SNR in two ways: the amplitude of applied force and the integration time.  So we are limited in two ways: stability of the lock to applied forces and time of locklosses / calibration fluctuations.

  12844   Wed Feb 22 08:54:17 2017 steveUpdatePEM PSL enclousure particle count

ETMX sus damping recovered.  PSL enclousure is dusty at 20V rotation speed. Rainy days as outside condition.

Quote:

The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am.

The HEPA filter speed at the Variac was turned down to 20V from 40

This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.

 

 

Attachment 1: dusty__PSL.png
dusty__PSL.png
  12843   Tue Feb 21 17:05:14 2017 SteveUpdateGeneralProjector lamp replaced

This bulb was blown out on Feb 4, 2017 after 2 months of operation.

 

Attachment 1: blownup.jpg
blownup.jpg
  12842   Tue Feb 21 13:51:35 2017 CraigSummaryGeneralAlternative Calibration Scheme

We get SNR in two ways: the amplitude of applied force and the integration time.  So we are limited in two ways: stability of the lock to applied forces and time of locklosses / calibration fluctuations.

At the sites, you probably know that we blow our spectrum out of the water with the calibration lines, with SNRs of about 100 on the scale of about 10 seconds.  For us this might be impossible, since we aren't as quiet.

If we want 1% calibration on our sweeps, we'll need  0.01 = Uncertainty = sqrt( (1 - COH^2)/(2 * Navg * COH^2) ), where COH is the coherence of the transfer function measurement and Navg is the number of measurements at a specific frequency.  This equation comes from Bendat and Piersol, and is subject to a bunch of assumptions which may not be true for us (particularly, that the plant is stationary in time).

If we let Navg = 10, then COH ~ 0.999.

Coherence = Gxy^2/(Gxx * Gyy), where x(t) and y(t) are the input signal and output signal of the transfer function measurement, Gxx and Gyy are the spectral densities of x and y, and Gxy is the cross-spectral density.  

Usually SNR = P_signal / P_noise, but for us SNR = A_signal / A_noise.

Eric Q and Evan H helped me find the relationship between Coherence and SNR:

P = Pn + Pc, Pn = P * (1 - Coh), Pc = P * Coh

==> SNR = sqrt( Pc / Pn ) = sqrt( Coh / 1 - Coh )

From Coh ~ 0.999, SNR ~ 30.

Quote:

Question for Craig: What does the SNR of our lines have to be? IF we're only trying to calibrate the actuator in the audio band over long time scales, it seems we could get by with more frequency noise. Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?

 

  12841   Tue Feb 21 10:08:35 2017 steveUpdatePEMnoisy morning

Our new janitor Francisco is started working in IFO room today.

Quote:

The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am.

The HEPA filter speed at the Variac was turned down to 20V from 40

This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.

 

Large film crews are working just out side  the north west corner of the lab. They started around ~ 5:30am  Do not plan on working late tonight.

ETMX sus damping restored.

C1:PSL-FSS_RMTEMP, C1:PSL-PMC_PMCTRANSPD and C1:PEM-count_temp channels are not reading since Friday

 

Attachment 1: outside_activity.png
outside_activity.png
  12840   Sat Feb 18 21:50:48 2017 gautamUpdateIMCWFS servos turned back on

Here is a comparison of the error signal spectra after increasing the IMC modulation depth, to the contribution with RF inputs / whitening inputs terminated (which I borrowed from Koji's characterization of the same in Dec 2016, these shouldn't have changed).

Some general observations:

  1. This data was taken with the WFS servos disabled, but with the IMC hand-aligned to a good state (MC_TRANS ~15,000). The error signal spectra are from the new DQ channels (but still sampled at 2048Hz, I had not implemented the change to 512Hz).
  2. The error signals seem to have increased by ~25x yes, which is consistent with how much we expect the modulation depth to have increased
  3. The bump around 1 Hz is now cleaerly visible in all 16 channels, as is the bounce peak at 16Hz (relative to Dec 2016). In general, between 0.1Hz and 5Hz, there is now a fair bit of daylight between the error signals and the electronics noise contribution. 

I will update with the in-loop error signal spectra, which should give us some idea of the loop bandwidth.


I will look into lowering the sampling rate, and how much out-of-band power is aliasing into the 0-256 Hz band and update with my findings.

Quote:

Yikes. Please change the all teh WFS DQ channels sample rates from 2048 down to 512 Hz. I doubt we ever need anything about 180 Hz.

There is sometimes an issue with this: if our digital AA filters are not strong enough, the noise about above 256 Hz can alias into the 0-256 Hz band. We ought to check this quantitatively and make some elog statement about our AA filters. This issue is also seen in DTT when requesting a low frequency spectrum: DTT uses FIR filters which are sometimes not sharp enough to prevent this issue.

 

 

Attachment 1: WFS_error_noise.pdf
WFS_error_noise.pdf
  12839   Sat Feb 18 14:09:06 2017 ranaUpdateIMCWFS servos turned back on

Yikes. Please change the all teh WFS DQ channels sample rates from 2048 down to 512 Hz. I doubt we ever need anything about 180 Hz.

There is sometimes an issue with this: if our digital AA filters are not strong enough, the noise about above 256 Hz can alias into the 0-256 Hz band. We ought to check this quantitatively and make some elog statement about our AA filters. This issue is also seen in DTT when requesting a low frequency spectrum: DTT uses FIR filters which are sometimes not sharp enough to prevent this issue.

 

  12838   Fri Feb 17 20:10:18 2017 gautamUpdateIMCWFS servos turned back on

[Koji, gautam]

Turns out the "problem" with WFS2 and the apparent offset accumulation on the IMC Servo board is probably a slow machine problem.

Today, Koji and I looked at the situation a little more closely. This anomalous behaviour of the C1:IOO-MC_SUM channel picking up an offset seems correlated with light being incident on WFS2 head. Placing an ND filter in front of WFS 2 slowed down the rate of accumulation (though it was still present). But we also looked at the in-loop error signal on the IMC board (using the "Out 2" BNC on the front panel), and this didn't seem to show any offset accumulation. Anyways, the ability of the Autolocker doesn't seem to be affected by this change, so I am leaving the WFS servo turned on.

The new demod phases (old +45degrees) and gains (old gains *0.2) have been updated in the SDF table. It remains to see that the WFS loops don't drag the alignment over longer timescales. I will post a more detailed analysis here over the weekend...

Also, we thought it would be nice to have DQ channels for the WFS error signals for analysis of the servo (rather than wait for 30 mins to grab live fine resolution spectra of the error signals with the loop On/Off). So I have added 16 DQ channels [recorded at 2048 Hz] to the c1ioo model (for the I and Q demodulated signal from each quadrant for the 8 quadrants). The "DRATE" for the c1ioo model has increased from ~200 to 410. Comparing to the "DRATE" of c1lsc, which is around 3200, we think this isn't significantly stretching the DAQ abilities of the c1ioo model...

 

  12837   Fri Feb 17 20:04:43 2017 KojiUpdateGeneralProjector not functional / Zita partially working

Koji, Gautam, Johannes

We quickly checked the situation of the projector in the control room.

- We found that the proejctor was indicating "lamp error".
==> Steve, could you remove the projector from the ceiling and check if it still does not work?
If it still does not work, send it back to the vender. It should be covered by the previous service.

- Zita seemed happy with the DVI output. We tried the dual display configration and  VGA and DVI are active right now.
The DVI output (from RADEON something video card) is somewhat strange. We probably need to look into the video display situation.

  12836   Fri Feb 17 10:56:12 2017 steveUpdatePEMparticle counter moved into PSL enclousure

The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am.

The HEPA filter speed at the Variac was turned down to 20V from 40

This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.

 

Attachment 1: from_here.jpg
from_here.jpg
Attachment 2: to_here.jpg
to_here.jpg
Attachment 3: PSL_particles.png
PSL_particles.png
  12835   Thu Feb 16 21:55:47 2017 ranaSummaryGeneralAlternative Calibration Scheme

Question for Craig: What does the SNR of our lines have to be? IF we're only trying to calibrate the actuator in the audio band over long time scales, it seems we could get by with more frequency noise. Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?

  12834   Thu Feb 16 13:29:38 2017 gautamSummaryGeneralAlternative Calibration Scheme

Summary:

Craig and I have been trying to put together a Simulink diagram of the proposed alternative calibration scheme. Each time I talk the idea over with someone, I convince myself it makes sense, but then I try and explain it to someone else and get more confused. Probably I am not even thinking about this in the right way. So I am putting what I have here for comments/suggestions.

What's the general idea?

Suppose the PSL is locked to the MC cavity, and the AUX laser is locked to the arm cavity (with sufficiently high BW). Then by driving a line in the arm cavity length, and beating the PSL and AUX lasers, we can determine how much we are modulating the arm cavity length in metres by reading out the beat frequency between the two lasers, provided the arm cavity length is precisely known.

So we need:

  1. Both lasers to be stabilized to be able to sense the line we are driving
  2. A high bandwidth PDH loop for locking the AUX laser to the arm cavity such that the AUX laser frequency is able to track the line we are driving
  3. An accurate and precise way to read out the beat frequency (the proposal here is to use an FPGA based readout)
  4. An accurate measurement of the arm length (I think we know the arm lengths to <0.1% so this shouldn't dominate any systematic error).

To be able to sense a 1kHz line being driven at 1e-16 m amplitude, I estimate we need a beat note stability of ~1mHz/rtHz at 1kHz.

Requirements and what we have currently:

  • The PSL is locked to the mode-cleaner, and the arm cavity is locked to the PSL. The former PDH loop is high BW, and so we expect the stabilized PSL to have frequency noise of ~1mHz/rtHz at about 1kHz (to be measured and confirmed)
  • The AUX laser is locked to the arm cavity with a medium-BW (~10kHz UGF) PDH servo. From past out-of-loop ALS beat measurements, I estimate the expected frequency noise of the AUX laser at 1kHz to be ~1Hz/rtHz with the current PDH setup
  • Rana suggested we "borrow" the stability of the PSL by locking the AUX laser and PSL in a high bandwidth PLL - if we want this loop to have ~300kHz BW, then we need to use an EOM as an actuator. The attached Simulink diagram (schematic representation only, though I think I have measurements of many of those transfer functions/gains anyways) shows the topology I had in mind. Perhaps I did not understand this correctly, but if we have such a loop with high gain at 1kHz, and the error signal being the beat between PSL and AUX, won't it squish the modulation we are applying @1kHz?
  • Is it feasible to instead add a parallel path to the end PDH loop with an EOM as an actuator (similar to what we do for the IMC locking)? Ideally, what we want is an end PDH loop which squishes the free-running NPRO noise to ~1mHz/rtHz at 1kHz instead of the 1Hz/rtHz we have currently. This loop would then also have negligible tracking error at 1kHz. Then, we could have a low bandwidth PLL offloading onto the temperature of the crystal to keep the beat between the two lasers hovering around the PSL frequency.

Hardware:

On the hardware side of things, we need:

  • Broadband EOM
  • FSS box to drive the EOM (Rana mentioned there is a spare available in the Cryo lab)

Koji and I briefly looked through the fiber inventory we have yesterday. We have some couplers (one mounted) and short (5m) patch fibers. But I think the fiber infrastructure we have in place currently is adequate - we have the AUX light brought to the PSL table, and there is a spare fiber running the other way if we want to bring the PSL IR to the end as well.

I need to also think about where we can stick the EOM in given physical constraints on the EX table and the beam diameter/aperture of EOM...

Attachment 1: AltCal.pdf
AltCal.pdf
  12833   Wed Feb 15 23:54:13 2017 gautamUpdateIMCIMC saga continues...

Following the discussion at the meeting today, I wanted to finish up the WFS tuning and then hand over the IFO to Johannes for his loss stuff. So I did the following:

  1. First I set the dark offsets on the WFS (with PSL shutter closed). Then I hand aligned the MC to maximize transmission, centered the beam on the WFS, and set the RF offsets with the MC unlocked.
  2. Given that the demod phase for the IMC PDH demodulation board changed by |45 degrees|, I tried changing the digital demod phases in each of the WFS quadrant signals by +/- 45 degrees. Turns out +45 degrees put all the error signal into the I Phase, which is what we use for the WFS loops.
  3. Then I attempted to check the WFS loops. I estimated that we have ~25 times the modulation depth now, so I reduced the WFS1/2 P/Y gains by this factor (but left the MC2 TRANS P/Y gains as is). The loop gain seemed overall too low, so I upped the gain till I saw instability in the loop (error signals ringing up). Then I set the loop gains to 1/3 of this value - it was 0.01 before, and I found the loop behaved well (no oscillations, MC TRANS stabilized) at a gain of 0.002.

At this point, I figured I would leave the WFS in this state and observe its behaviour overnight. But abruptly, the IMC behaviour changed dramatically. I saw first that the IMC had trouble re-acquiring lock. Moreover, the PC Drive seemed saturated at 10.0V, even when there was no error signal to the MC Servo board. Looking at the MEDM screen, I noticed that the "C1-IOO_MC_SUM_MON" channel had picked up a large (~3V) DC offset, even with In1 and In2 disabled. Moreover, this phenomenon seemed completely correlated with opening/closing the PSL shutter. Johannes and I did some debugging to make sure that this wasn't a sticky button/slider issue, by disconnecting all the cables from the front panel of the servo board - but the behaviour persisted, there seemed to be some integration of the above-mentioned channel as soon as I opened the PSL shutter.

  

 

Next, I blocked first the MC REFL PD, and then each of the WFS - turns out, if the light to WFS2 was blocked and the PSL shutter opened, there was no integrating behaviour. But still, locking the MC was impossible. So I suspected that something was wrong with the LO inputs to the WFS Demod Boards. Sure enough, when I disconnected and terminated those outputs of the RF distribution box, I was able to re-lock the MC fine.

I can't explain this bizzare behaviour - why should an internal monitor channel of the MC Servo board integrate anything when the only input to it is the backplane connector (all front panel inputs physically disconnected, In1 and In2 MEDM switches off)? Also, I am not sure how my work on the WFS could have affected any hardware - I did not mess around at the 1X1 rack in the evening, and the light has been incident on the WFS heads for the past few days. The change in modulation depth shouldn't have resulted in the RF power in this chain crossing any sort of damage threshold since the measured power before the changes was at the level of -70dBm, and so should be at most -40dBm now (at the WFS demod board input). The only thing different today was that the digital inputs of the WFS servos were turned on...

So for tonight I am leaving the two outputs of the RF distribution box that serve as the LO for the WFS demod boards terminated, and have also blocked the light to both WFS with beam blocks. The IMC seems to be holding lock steady, PC drive levels look normal...


Unrelated to this work, but I have committed to the svn the updated versions of the mcup and mcdown scripts, to reflect the new gains for the autolocker...

  12832   Wed Feb 15 22:21:12 2017 LydiaUpdateDAQpanels and pcbs

This is already how it's hooked up. The hole on the from that says +24 V is for an indicator light.

Quote:

The amplifier unit should use the three pin dsub connectors (3w3?) that we use on many of the other units for DC power, and preferably go through the back panel. You can leave out the negative pin, since you just need +24 and ground.

 

  12831   Wed Feb 15 22:16:05 2017 Max IsiUpdateSummary PagesNew condor_q format

There has been a change in the default format for the output of the condor_q command at CIT clusters. This could be problematic for the summary page status monitor, so I have disabled the default behavior in favor of the old one. Specifically, I ran the following commands from the 40m shared account: mkdir -p ~/.condor echo "CONDOR_Q_DASH_BATCH_IS_DEFAULT=False" >> ~/.condor/user_config This should have no effect on the pages themselves.

  12830   Wed Feb 15 09:06:13 2017 ericqUpdateDAQpanels and pcbs

The amplifier unit should use the three pin dsub connectors (3w3?) that we use on many of the other units for DC power, and preferably go through the back panel. You can leave out the negative pin, since you just need +24 and ground.

  12829   Wed Feb 15 00:26:44 2017 JohannesUpdateDAQpanels and pcbs

I finished designing the PCBs for the VME crate back sides (see attached). The project files live on the DCC now at https://dcc.ligo.org/LIGO-D1700058. I ordered a prototype quantity (9) of the PCB printed and bought the corresponding connectors, all will arrive within the next two weeks. See also attached the front panels for the Acromag DAQ chassis and Lydia's RF amplifier unit (the lone +24V slot confuses me: I don't see a ground connector?). On the Acromag panel, six (3x2) of the DB37 connectors are reserved for VME hardware, two are reserve, and I filled the remaining space with general purpose BNC connectors for whatever comes up.

Attachment 1: acromag_chassis_panel.pdf
acromag_chassis_panel.pdf
Attachment 2: vme_backplane_panel.pdf
vme_backplane_panel.pdf
Attachment 3: rfAmp.pdf
rfAmp.pdf
  12828   Tue Feb 14 10:43:06 2017 gautamBureaucracyEquipment loanEquipment to Cryo Lab

PZT Buzzer Box (Thorlabs HV Supply + Manual + 2*PZT Buzzers) ---> Cryo Lab (Brittany + Aaron)

  12827   Mon Feb 13 19:44:55 2017 LydiaUpdateIMCFront panel for 29.5 MHz amplifier box

I made a tentative front panel design for the newly installed amplifier box. I used this chassis diagram to place the holes for attaching it. I just made the dimensions match the front of the chassis rather than extending out to the sides since the front panel doesn't need to screw into the rack; the chassis is mounted already with separate brackets. For the connector holes I used a caliper to measure the feedthroughs I'm planning to use and added ~.2 mm to every dimension for clearance, because the front panel designer didn't have their dimensions built in. Please let me know if I should do something else. 

The input and coupled output will be SMA connectors since they are only going to the units directly above and below this one. The main output to the EOM is the larger connector with better shielded cables. I also included a hole for a power indicator LED. 

EDIT: I added countersinks for 4-40 screws on all the screw clearance holes. 

Johannes, if you're going to be putting a front panel order in soon, please include this one. 

Also, Steve, I found a caliper in the drawer with a dead battery and the screws to access it were in bad shape- can this be fixed? 

 

Attachment 1: rfAmp.pdf
rfAmp.pdf
  12826   Mon Feb 13 17:39:45 2017 AshleyUpdateGeneralPreliminary Microphone Data Update
  • Problems that have occurred since my last post: All of the sudden, I was getting very strange data that was very quiet and did not match the previous input range of my last locations (see attachment). After resoldering the custom bnc connection cables with Lydia, which were in disrepair, and checking almost everything we could think of, we found that the gain dial on the preamp was turned all the down. Immediately after it was fixed, the data returned to expected values (based on neighboring locations and data taken at the last location before the problem occurred). 
  • Updates: Since my last post, I have created a normalized blrms color map in addition to the one I already have. Additionally, I have started working on plotting the color maps next to a labeled, to-scale drawing of the lab, but have yet to complete it. 
  • Attachment 1: comparison of the psds
  • Attachment 2: blrms color map
  • Attachment 3: normalized color map
Quote:

Brief Summary: I am currently looking at the acoustic noise around both arms to see if there are any frequencies from machinery around the lab that stand out and to see what we can remove/change. I am using a Bluebird microphone suspended with surgical tubing from the cable trays to isolate it from vibrations. I am also using a preamp and the SR875 spectrum analyzer taking 6 sets of data every 1.5 meters (0 to 200Hz, 200Hz to 400Hz, 400z to 800Hz, 800Hz to 3200Hz, 3.2kHz to 12kHz, 12kHz to 100kHz).

 

·                Attachment 1 is a PSD of the first 3 measurements (from 0 to 12kHz) that I took every 1.5 meters along the x arm with the preamp and spectrum analyzer

·                Attachment 2 is a blrms color map of the first 6 sets of data I took (from 2.4m to 9.9m) 

·                Attachmetn 3 is a picture of the microphone set up with the surgical tubing 

Problems that occurred: settings on the preamp made the first set of data I took significantly smaller than the data I took with the 0dB button off and the last problem I had was the spectrum analyzer reading only from -50 to -50 dBVpk

 

 

 

Attachment 1: figure_1.png
figure_1.png
Attachment 2: x_and_y_blrms_03.png
x_and_y_blrms_03.png
Attachment 3: xblrms_median.png
xblrms_median.png
  12825   Mon Feb 13 17:19:41 2017 yinziConfiguration configuring ethernet for raspberry pi

Gautam and I were able to get the Raspberry Pi up and running today, including being able to ssh into it from the control room.

Below are some details about the setup/procedure that might be helpful to anyone trying to establish Ethernet connection for a new RPi, or a new operating system/SD card.

Here is the physical setup:

 

The changes that need to be made for a new Raspbian OS in order to communicate with it over ssh are as follows, with links to tutorials on how to do them:

1. Edit dhcpcd.conf file: https://www.modmypi.com/blog/how-to-give-your-raspberry-pi-a-static-ip-address-update

2. Edit interfaces file: https://www.mathworks.com/help/supportpkg/raspberrypi/ug/getting-the-raspberry_pi-ip-address.html

3. Enable ssh server: http://www.instructables.com/id/Use-ssh-to-talk-with-your-Raspberry-Pi/

 

The specific addresses for the RPi we set up today are:

IP Address: 192.168.113.107

Gateway/Routers/Domain Name Servers: 192.168.113.2

Netmask: 255.255.255.0

GV: I looked through /etc/var/bind/martian.hosts on chiara and decided to recycle the IP address for Domenica.martian as no RPis are plugged in right now... I'm also removing some of the attachments that seem to have been uploaded multiple times.

ELOG V3.1.3-