40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 85 of 344  Not logged in ELOG logo
ID Date Author Typedown Category Subject
  6077   Tue Dec 6 21:37:08 2011 JenneUpdateRF SystemNew EOM mount in place

EOM is remounted on the fancy-pants new mount that I crafted.  EOM is also aligned.  2 green mirrors (the first ones to see the beams coming onto the PSL table from the arm transmissions) had to be moved so I could fit the mount in, since the new mount is bigger than the old one.  I put them back, and approximately realigned them, but didn't do any fine alignment.  This must be done before looking at beatnotes again.

After playing with the EOM, the MC was flashing on higher order modes.  The PSL beam has been realigned to make the MC lock on TEM00, and Suresh helped me center on the WFS and MC2T.

Things look okay for now.  Next step:  Kiwamu needs to find his happy mode cleaner place, and we'll realign the PSL beam to the MC.  The PSL-MC axes were mismatched pretty badly according to Suresh anyway, so this had to be done no matter what.

  6078   Wed Dec 7 00:11:58 2011 DenUpdateAdaptive FilteringOfflineAF

 I did offline adaptive filtering with yesterday's 3 hours of MC-F and GUR1X data. It turns out that normalized-lms can strongly outperform static Wiener filtering!

offlineaf_psd.png 

This is interesting. It might be something inside MC_F that Wiener static does not see. I think the problem is either with seismometer noise or tilt.

Attachment 2: offlineaf_coh.png
offlineaf_coh.png
  6079   Wed Dec 7 00:48:58 2011 kiwamuUpdateRF SystemRealigned incindent pointing to MC
Actually it was already in a good place.
I just realigned the zig-zag mirrors on the PLS table to bring the entire beam axis a little bit upward.
The WFS servo still seems fine. The input pzt mirrors are still within their range.

Quote from #6077

Next step:  Kiwamu needs to find his happy mode cleaner place, and we'll realign the PSL beam to the MC.  The PSL-MC axes were mismatched pretty badly according to Suresh anyway, so this had to be done no matter what.

  6080   Wed Dec 7 02:55:38 2011 kiwamuUpdateGreen Lockinglocking activity tonight

No real progress.

Probably I spent a bit too much time realigning the beat-note optical path.

 

(what I did)

 - Switched on a power supply which was supposed to give +/- 15V for the broadband beat-note PD.
   The power supply had been somehow turned off.
 - Realigned the beat-note path. When we installed the new EOM mount today, we moved some of the green steering mirrors to make a space.
   So we had to realign the downstream of the beat-note path. After the realignment the DC output of the PD was about 120 mV and the signal level of the beat-note was at -20 dBm.
 - Took noise spectrum of the beat-note with the arm cavity locked by the IR-PDH
    The noise curve was almost the same as before (i.e. unknown high frequency white noise above 20 Hz and some low frequency noise which has structures at 1 and 3 Hz).
-  Closed the ALS loop with the coarse sensor. But I was too lazy to go further more. 

Quote from #6076
Tomorrow I will try :
  (1) Using the fine sensor.
  (2) Noise budgeting with the fine sensor.

  6082   Wed Dec 7 18:47:36 2011 JenneUpdateRF SystemRAM Mon is now being demodulated

There were 2 open outputs on the splitter in the RAMmon (formerly known as Stochmon) box underneath the BS oplev table.  The input to the splitter comes from the Thorlabs PD that we're using as our RAM monitoring PD.  2 of the outputs go to the RMS detection of 11 and 55 MHz.  Now the other 2 (previously terminated) outputs go over to the LSC rack via SMA cable.  The signal on both channels is ~200mV pk-pk, so -10dBm.  One is plugged into the AS11 demod board (which didn't have a PD input yet), and the other goes to POP55's demod board, so POP55 is not what you think it is for now.

Koji is working on checking out the Rich box, which has 4 demodulators, which we will use eventually.  Right now we're just using the already-plugged-in demod boards so we can start looking at some trends of RAM.  We're going to need to find some channels when we're ready for the switchover.

Zach is nearing completion of the mini-update to the temp sensing system.  Once we have the new more sensitive temp sensor in place, we can have a look-see at the similarities between EOM temperature and RAM levels.

  6083   Wed Dec 7 20:55:44 2011 Vladimir, DenUpdatedigital noiseMatlab error

Quote:

It would be useful to see some plots so we could figure out exactly what magnitude and phase error correspond to "gross" and "miserable".

To show why Matlab is bad in filtering at small cut-off frequencies we did the same thing in Matab, Octave and R: we've taken the low-pass chebyshev filter of the type 1, order 6, ripple 1 dB, the sampling frequency was 16384 Hz and cut-off frequency varied from 1 to 1000 Hz. Here is the plot for the gain of the zpk model versus to cut-off frequency.

gain_cmp.png

We can see that Matlab's gain shows surprising gains for low cut-off frequencies through for > 100 Hz it is fine. In the next table we compare gain from Foton, Matlab, R and Octave for the same filter. So Foton is also good

freq R_gain matlab_gain octave_gain Foton_gain
1 3.05186270655452e-24 4.8824152e-22 3.05186271e-24 3.05186e-24
10 3.04698335947093e-18 1.8268825e-16 3.04698336e-18 3.04698e-18
100 2.99910841393644e-12 2.9991084e-12 2.99910841e-12 2.99911e-12
1000 2.60247212721439e-06 2.6024721e-06 2.60247213e-06 2.60247e-06
  6084   Thu Dec 8 00:04:50 2011 ranaUpdateIOORAM Mon is now being demodulated

Monitoring good, but remember that the EOM alignment must be done carefully to minimize the RAM before we can use these trends.

  6086   Thu Dec 8 00:45:13 2011 KojiUpdateRF System4ch demod is ready

I have tested the left 2ch of 4ch demod board.

The left most is for 11MHz, and the next one is for the 55MHz.

  6087   Thu Dec 8 01:26:31 2011 ZachUpdateRF SystemEOM temp sensor modified

I have modified the EOM temperature sensor circuit for the temperature vs. RAM long-term measurements. The only real change is that the sensor is a 100-kOhm thermistor, instead of a 100-Ohm RTD. These semiconductor thermistors (DigiKey P/N 317-1377-ND) are highly nonlinear and can be much more responsive than RTDs, but this difference is much more noticeable at low temperatures.

Frank had told me that the fractional response of the thermistors was so much higher that I could scale the bridge drive current down by the same factor as the resistance was increasing (i.e., 1 mA -> 1 uA, commensurate with 100 ohms -> 100k) and still see a marked improvement. It turns out that at room temperature for this particular sensor the gain enhancement would only be about ~10x, so I only reduced the drive current to ~10 uA, by INCREASING the drive voltage from ~0.1 V -> 1 V, improving the enhancement to ~100x.

Below is a plot of the real nonlinear response of the thermistor, along with a linear approximation at 298.15 K, which gives a coefficient of ~ -4.67 kOhms/K. The differential bridge output voltage response for the new resistance and current is ~7.5 uV/Ohm 2.5 uV/Ohm, bringing the total temperature response before amplification to ~35 mV/K 11.6 mV/K. Looking at a trend of the FSS_RMTEMP channel over a month, we saw that the maximum PSL table temperature fluctuations were ~2 Kpp, so we aimed the maximize resolution by matching +/- 2 K with +/-10 V at the ADC. This was done by using a gain of ~300 in the AD620 that amplifies the differential bridge output. We found that a gain of ~300 put it pretty close, so the grand total calibration ~ 10.5 V/K 3.5 V/K.

Edit (ZK): I screwed up with calculating the bridge response by a factor of three somehow, so I have stricken and restated the calibrations above

 

 

100k_thermistor_response.png

I took a look at the recently acquired temperature data alongside the RAMmon 11 and 55 signals, and it appears that we're seeing the same sort of fringing effects we usually see, with oscillatory RAM levels for a monotonic change in EOM temperature.The odd bit towards the end is caused by the MC losing lock. 

It is going to be very interesting to find out what causes this fringing.

RAM_with_temp.png

  6088   Thu Dec 8 11:59:53 2011 ZachUpdateRF Systemfringing indeed

Here is a trend of 11 & 55 I&Q, along with the EOM temperature and PSL RMTEMP signals. You can see that there is definitely some fringe-like behavior for monotonic changes in temperature. This is consistent with what I have seen on the gyro table in the past.

Some other notes:

  • The EOM temperature (or at least the sensor temperature) seems to track RMTEMP almost exactly when there is no foam box on the EOM. I have verified that the max-min swing here is the same for both signals (~0.77 K).
  • Something crazy appears to happen at ~10:15, and all the RAM signals get much noisier. Does anyone know what happened at this time (2:15am local)?

We ought to get to the bottom of the fringing. The CTE of LiNbO3 is ~2 ppm/K, so given that the wavelength is on the order of 0.5 K, this is probably not caused by the etalon effect (2ppm/K * 0.5K * ~1cm << 1064nm).

RAM_with_temp_overnight.png

  6089   Thu Dec 8 14:47:28 2011 JenneUpdateIOOEOM aligned to minimize RAM

Quote:

Monitoring good, but remember that the EOM alignment must be done carefully to minimize the RAM before we can use these trends.

 I temporarily diverted the output of the RAMmon PD to a spectrum analyzer (4195 in Spectrum Analyzer mode), and tweaked the EOM alignment until I minimized the 11 and 55 MHz peaks as much as possible.  It was possible to get each individual peak to disappear into the noise (about -70dBm), but to get both minimized simultaneously I wasn't able to get both down into the noise.  I left the 11MHz at about -55dBm, and the 55MHz at about -60dBm.  If Kiwamu's simulation tells us that one is more significant than the other (55, because we use it for MICH?), then we can decide to favor putting that peak in the noise and sacrifice ~10dB in the other peak. 

When I first plugged the PD into the analyzer, I saw 22MHz and 44MHz (small) peaks, but they went away after the first bit of tweaking.

Before having used the analyzer, I was trying to minimize the demodulated signals via StripTool, but that was a slow process.  The spectrum analyzer was obviously much faster.

The PD has been returned to the regular RAMmon electronics.

Next up: putting in the new demod box that Koji tested last night.

  6090   Thu Dec 8 16:54:05 2011 JenneUpdateRF SystemInstallation of new demod box

So far:

* New demod box has been placed in the LSC rack.

* An extra set of +\- 24V has been prepared at the terminal block where all the Crates get their power on the LSC rack.  The grounds were all connected up, but the hot wires weren't.  So there were extra spots available, but none that were pre-wired with my voltages.

     * To do this I turned off all the power supplies in the short rack, since I decided to be a live chicken rather than a dead duck.  After hooking up the new terminal block slots, I turned on the power supplies.

 * Make a power cable to go from the terminal block to the box

Still to do:

 * Connect the spare 55MHz LO and the POP (or POX or POY) unused 11MHz LO to the back of the box

 * Move the PD inputs to the new demod box rather than the borrowed AS11 and POP55 boards

 * Plug the I & Q outs for each freq into some spare ADC channels - must first make sure we have 4 open channels.

 * See if it works.

  6091   Thu Dec 8 19:48:23 2011 kiwamuUpdateCDSrestarted c1lsc machine and daqd

Since the c1lsc machine became frozen I restarted the c1lsc machined and daqd.

Then I burtrestored c1lsc, c1ass and c1oaf to this evening. They seem running okay.

  6092   Thu Dec 8 22:44:55 2011 KojiUpdateRF System4ch demod test result

1) Linearity Test

LO input level was +10dBm. The LO freq was 11MHz and 55MHz for CH1 and CH2 respectively.
The IF frequency was fixed at 10kHz.

The amplitude of the RF input was swept from -50dBm to +15dBm.
Basically I and Q output of CH1 and CH2 was quite linear in this amplitude range.

2) Freqency Response

RF input was fixed at -20dBm and the IF frequency was swept from 1kHz to 1MHz.

The response was flat upto 100kHz, and have sensitivity upto 300kHz.

3) Output noise

Noise floor of the output is ~20nV/rtHz. All of the channels behave in the same way.
1/f start from 100Hz.

Attachment 1: RF_DEMOD_TEST_111208.pdf
RF_DEMOD_TEST_111208.pdf RF_DEMOD_TEST_111208.pdf RF_DEMOD_TEST_111208.pdf
  6093   Fri Dec 9 13:28:09 2011 DenUpdateAdaptive FilteringC1OAF

I tried to figure out why red NO SYNC label became present in the C1OAF_GDS_TP screen after I added AA filters to the C1OAF model.

C1OAF model contains 8 libraries C1OAF_ADAPT for 8 DOF. I changed C1OAF_ADAPT library to C1OAF_ADAPT_AA library where I added 28 AA filters for 28 witness channels. It turns out that if I use this library for all 8 DOF then I see NO SYNC label, if only for one DOF (MCL) then I see green IOP label. This means that using AA filters for each DOF too much channels of filters are created for online system to operate. I think there is some number inside the code that one can not exceed. Analyzing compilation output after "make c1oaf" I figured out that without using AA filters we have 632 filters and using AA we have 856 filters.

For now I'll use AA filters for MCL only.

  6094   Fri Dec 9 14:33:16 2011 Alex IvanovUpdateAdaptive FilteringC1OAF

Quote:

I tried to figure out why red NO SYNC label became present in the C1OAF_GDS_TP screen after I added AA filters to the C1OAF model.

C1OAF model contains 8 libraries C1OAF_ADAPT for 8 DOF. I changed C1OAF_ADAPT library to C1OAF_ADAPT_AA library where I added 28 AA filters for 28 witness channels. It turns out that if I use this library for all 8 DOF then I see NO SYNC label, if only for one DOF (MCL) then I see green IOP label. This means that using AA filters for each DOF too much channels of filters are created for online system to operate. I think there is some number inside the code that one can not exceed. Analyzing compilation output after "make c1oaf" I figured out that without using AA filters we have 632 filters and using AA we have 856 filters.

For now I'll use AA filters for MCL only.

 I have a feeling we are not fitting into pre-allocated memory space in the shared memory between the front-end process and the epics process. Filter module data is overwriting some other data and that's why we are not getting a sync light. I suggest we upgrade to 2.4 code first and then we will figure out a way to expand memory areas to fit 856 filters.

  6095   Fri Dec 9 15:14:41 2011 DenUpdateCDSrelease 2.4

Alex has created a 2.4 branch of the RCD. Jamie, we can try to compile and install it. As a test a did it for c1oaf, it compiles, installs and runs once variables SITE, IFO, RCD_LIBRARY_PATH are properly defined. As we do not want to run one model at 2.4 code and others at 2.1, I recompiled c1oaf back to 2.1. Jamie, please, let me know when you are ready to upgrade to 2.4 release.

  6096   Fri Dec 9 15:49:24 2011 JenneUpdateIOOMC trans is way down

I was looking at the trends from the RAMmon, since I did the EOM alignment yesterday, and wanted to compare them to the MC trans, just to make sure the MC was locked during the times I'm examining.  I was dismayed to discover that the MC has lost its oomph, starting around 11:30 this morning.  Den was the only person in the lab to my knowledge at that time, and he claims that he didn't touch the MC until well after lunch.  As you can see from the 8 hour trend attached, we went from normal ~26000 counts to ~15000, and we're slowly decaying from there.

MC refl looks pretty bad on the camera, particularly in YAW.  Investigations are beginning now....

Edit, ~10min later...  I enabled the WFS (I don't know why they were off...when the MC fell out of lock and relocked itself, the WFS didn't come on), and things went basically back to how they should be.  However, the sans-WFS alignment is still totally crappy, so the PSL beam probably needs to be aligned to the MC.  I don't really want to touch the alignment though without an okay from Kiwamu, so I'll wait for him to come in and confirm that he's happy with the current MC.

Attachment 1: MCtrans_9Dec2011.png
MCtrans_9Dec2011.png
  6097   Fri Dec 9 17:08:41 2011 JenneUpdateRF SystemLots of current used in Rich's demod box

I checked the power regulators on the Rich demod box (according to the schematic, D1000217).  The positive one is LM2941CT, and the negative one is LM2991T.  Both accept input voltage up to +26V or -26V respectively.  So my use of +\- 24V to be regulated down to +\- 15V isn't too crazy.  It's a little crazy, but not too crazy.  They recommend having only a 3V difference between the input and output voltages.  We don't have any 18V or 20V power supplies in the regular LSC power supply rack, so Rana suggested using the 24's. 

When I plug in and turn on the Rich box, the current on the +24V power supply goes up by about 0.8A, and the -24V supply goes up by about 0.3A.  That seems like kind of a lot.  Is that too much?  Do I need to find a better plan that involves +\- 18V?  Thoughts?

For now, the Rich box is off, just in case.

  6098   Fri Dec 9 17:15:29 2011 JenneUpdateIOOMC trans is way down

Quote:

I was looking at the trends from the RAMmon, since I did the EOM alignment yesterday, and wanted to compare them to the MC trans, just to make sure the MC was locked during the times I'm examining.  I was dismayed to discover that the MC has lost its oomph, starting around 11:30 this morning.  Den was the only person in the lab to my knowledge at that time, and he claims that he didn't touch the MC until well after lunch.  As you can see from the 8 hour trend attached, we went from normal ~26000 counts to ~15000, and we're slowly decaying from there.

MC refl looks pretty bad on the camera, particularly in YAW.  Investigations are beginning now....

Edit, ~10min later...  I enabled the WFS (I don't know why they were off...when the MC fell out of lock and relocked itself, the WFS didn't come on), and things went basically back to how they should be.  However, the sans-WFS alignment is still totally crappy, so the PSL beam probably needs to be aligned to the MC.  I don't really want to touch the alignment though without an okay from Kiwamu, so I'll wait for him to come in and confirm that he's happy with the current MC.

 Kiwamu and I discussed, and looking at the AS camera with the PRM and SRM misaligned, but MCWFS engaged, things look good.  This means that it's probably the MC that has drifted, and we want to align the MC back to the PSL beam.

  6099   Fri Dec 9 17:44:45 2011 KojiUpdateRF SystemLots of current used in Rich's demod box

Those asymmetric currents are same as what I saw with the table top +/-18V supply. If you really don't like it, there could be an option to disconnect CH3/4 in the box.

In any case, this could be a good long-run test of the demod box, couldn't it?

Quote:

I checked the power regulators on the Rich demod box (according to the schematic, D1000217).  The positive one is LM2941CT, and the negative one is LM2991T.  Both accept input voltage up to +26V or -26V respectively.  So my use of +\- 24V to be regulated down to +\- 15V isn't too crazy.  It's a little crazy, but not too crazy.  They recommend having only a 3V difference between the input and output voltages.  We don't have any 18V or 20V power supplies in the regular LSC power supply rack, so Rana suggested using the 24's. 

When I plug in and turn on the Rich box, the current on the +24V power supply goes up by about 0.8A, and the -24V supply goes up by about 0.3A.  That seems like kind of a lot.  Is that too much?  Do I need to find a better plan that involves +\- 18V?  Thoughts?

For now, the Rich box is off, just in case.

 

  6100   Fri Dec 9 17:53:31 2011 DenUpdateAdaptive FilteringC1OAF

[Jenne, Den]

AA filters for witness channels are added to the oaf model. It is working now and the number of memory used is not critical.  NO SYNC is not present any more.

  6101   Fri Dec 9 20:03:57 2011 ZachUpdateRF SystemLots of current used in Rich's demod box

D0902745-v5 (probably the AP1053's):

Screen_shot_2011-12-09_at_8.00.54_PM.png

Quote:

Those asymmetric currents are same as what I saw with the table top +/-18V supply. If you really don't like it, there could be an option to disconnect CH3/4 in the box.

In any case, this could be a good long-run test of the demod box, couldn't it?

Quote:

I checked the power regulators on the Rich demod box (according to the schematic, D1000217).  The positive one is LM2941CT, and the negative one is LM2991T.  Both accept input voltage up to +26V or -26V respectively.  So my use of +\- 24V to be regulated down to +\- 15V isn't too crazy.  It's a little crazy, but not too crazy.  They recommend having only a 3V difference between the input and output voltages.  We don't have any 18V or 20V power supplies in the regular LSC power supply rack, so Rana suggested using the 24's. 

When I plug in and turn on the Rich box, the current on the +24V power supply goes up by about 0.8A, and the -24V supply goes up by about 0.3A.  That seems like kind of a lot.  Is that too much?  Do I need to find a better plan that involves +\- 18V?  Thoughts?

For now, the Rich box is off, just in case.

 

 

  6102   Sat Dec 10 05:27:43 2011 kiwamuUpdateGreen Lockingstatus update of the Y arm green lock

Status update of the Y arm green lock:

  + Recent goal : automation of the single arm green lock

 

(Things done)

  • Implementation of some realtime LOCKIN modules to detect the sign of the error signals.
  • Modification of the realtime control model to accommodate the I/Q MFD signals, which will be available in the near future. (Of course the model file in the svn has been also updated)
  • Update of the medm screens.
  • Scripting of the auto-lock has been 30 % done.
  • Succeeded in automation of closing the ALS loop. (I have tried several times and no failure was observed so far)

(Things to be done)

  • Scripting a routine to detect the sign of the fine sensor signals.
  • Development of a clever length scan algorhythm.
  • Scripting handing off routines.
  • Implementation of some lock-success binary bits to define the ALS state.
  • Implementation of fail-safes.
  6103   Sun Dec 11 17:28:36 2011 kiwamuUpdateGreen Lockingstatus update of the Y arm green lock

Quote from #6102

  + Recent goal : automation of the single arm green lock 

As reported in the previous elog entry #6102, the realtime model and screens have been modified.
Here is a summary about what are new in the realtime model.
 
(What are new ?)
  • The top name of the channels has been changed from GCV to ALS      
    => Although the model name itself is still C1GCV to keep the current relations between other computers.
  • I and Q signals on each sensor.
  • LOCKIN modules to detect the sign of the error signals by shaking suspensions.
  • Offset adjusters, which are combination of a controllable epics value and a low pass filter, to allow a smooth length scan.
  • Input matrix. This branches the input signal to the DOFs as well as the LOCKIN modules.
  • Output matrix to allow some combination of actuation (e.g. DARM, CARM, MCL, etc.,)
  • Output switch to enable/disable any feedbacks to the suspensions
  • Output filters before the suspensions. These filters will be usually flat, but enable us to inject some signals and enable some limiters.
     
    Here is the latest medm screen for the modified realtime controller.
    It gives you the idea of how the latest model works.

 ALSscreens.png

  6104   Mon Dec 12 11:16:02 2011 JenneUpdateRF SystemFoam house on EOM

Foam house installed on EOM a few min ago.  We'll leave it until ~tomorrow, then try out the heater loop.

  6106   Mon Dec 12 13:02:08 2011 kiwamuUpdateCDSdaqd restarted

I have restarted the daqd process at 1:01 PM since I have added some new ALS's daq channels.

  6107   Mon Dec 12 15:24:21 2011 JenneUpdatePSLPMC and MC were both crappy - now realigned

PMC trans was only ~0.79, where it should be ~0.84 something.  The MC was also not stellar. 

I aligned the beam to the PMC, and am now getting PMC trans 0.837 .

Then I aligned the PSL zigzag to the MC, and got MC Refl down to ~0.6 . 

I then aligned the WFS to the unlocked MC, and the MC Trans QPD to the locked MC.

Things seem good.  MC axis is still in a good place, since we get good michelson fringes at the AS port.

  6108   Mon Dec 12 16:30:17 2011 JenneUpdateComputersDid someone just do something to fb??

Dataviewer couldn't connect to the framebuilder, so I checked the CDS status screen, and all the fb-related things on each model went white, then red, then computer-by-computer they came back green.  Now dataviewer works again.  Is someone secretly doing shit while not in the lab???  Not cool man!

  6109   Mon Dec 12 16:57:38 2011 JenneUpdateRF SystemRAMmon, 4 day trend

EOM was aligned to minimize the 11 and 55 MHz peaks in the RAMmon PD the other day (elog 6089), and was left with just the temperature sensor attached, no heater, no foam box.

Here is a 4 day trend:

EOM_tempSense_noFoam_noHeater_RAMmon_4days.png

I don't have a whole lot to say about this, other than there's a lot of stuff going on.  The craziness at the end is me realigning the PMC and MC since, as you can see, MC trans was way down.  The foam box was put on earlier today (elog 6104), so we'll see how that changes things over night.

  6110   Tue Dec 13 01:20:38 2011 DenUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

Quote:

[Jenne, Mirko, with supervision from Jamie]

We are starting to create the new OAF model, so that it works with the new CDS system. 

 Why did you place Matt's code inside the simulink library and use the same library for all DOFs? I think this won't work out. Inside the .c code there are static variables. If all DOF use the same ADAPT_XFCODE() function, it means that they all mess there signals and coefficients with each other! Or the RCD during the compilation creates a copy of the function with the name of a library name in front? For example, ADAPT_MCL_ADAPT_XFCODE(). But then in the RCG manual it is claimed to name the .c file the same.

This problem can be fixed by creating .c files with proper names for each DOF. But here a memory question may arise. For 1 DOF we now have 28 witness channel. If we have a several minute filter, we use 28 * 104(filter length) * 3 (FIR coefficients, adapt input, corr input) * 8 (number of bytes in 1 double)  = 6.7 Mb / DoF. For 8 DOF we'll allocate ~55 Mb of memory in the kernel. The c1lsc cache size is 6 Mb per cpu. So we are definitely out of cache and it will take some time for a processor to communicate with ram. I wonder if it is OKEY for us to allocate this amount of memory as static arrays inside the kernel.

Now we use 6.7 Mb of memory because it seems to be a mistake with placing the same function for all DOF and we actually allocate for 1.

 

  6111   Tue Dec 13 11:34:32 2011 JenneUpdateRF SystemRAMmon, 5 day trend

Now we've got another day of data, with the foam box on for the last 24hrs.

First plot is a 5 day trend so you can see that the RAM has gotten a little bit smaller, as has the temperature drift, but not by a whole lot.

EOM_tempSense_RAMmon_5days_last_day_withFoam_noHeater.png

Second plot is the last 19 hours (so excluding much of the time while I was realigning beams on the PSL table yesterday), to zoom in on just the time when the foam box was installed.

EOM_tempSense_withFoam_noHeater_RAMmon_1day.png

After lunch Zach and I are going to engage the heater to temperature stabilize the system, to see how that affects things.

In other news, the MC looks like it was fine for a good long time, and ~3 hours ago it went bad.  The mode that's flashing is really bad in both pitch and yaw.  I don't know what happened, but something is not so awesome. Edit: Steve said that he opened the PSL table at some point this morning to look around but not touch, and also it's Janitor Day, and Kevin comes in around 8ish. That doesn't mean I know the actual cause, but those are the only things that happened in the IFO room this morning that anyone is aware of.

  6112   Tue Dec 13 11:51:33 2011 JamieUpdateComputersDid someone just do something to fb??

Quote:

Dataviewer couldn't connect to the framebuilder, so I checked the CDS status screen, and all the fb-related things on each model went white, then red, then computer-by-computer they came back green.  Now dataviewer works again.  Is someone secretly doing shit while not in the lab???  Not cool man!

This happens on occasion, and I have reported it to the CDS guys.  Something apparently causes the framebuilder to crash, but I haven't figured out what it is yet.  I doubt this particular instance had anything to do with remote futzing.

  6113   Tue Dec 13 16:31:40 2011 ZachUpdateIOOPSL beam realigned into MC

The MC coupling had become re-shittified. As we need transmitted MC light for the RAMmon, I realigned the input beam to the MC. (Jenne said that the MC mode itself should be well aligned, so I just used the zigzag on the PSL). MC_REFL is now ~0.5-0.6.

  6114   Tue Dec 13 18:56:23 2011 ranaUpdateIOOPSL beam realigned into MC

 

 Of course, looking at the MC transmission os the important thing, but I wonder if maybe we should also monitor the beam before it goes into the MC just to see if its the fault of the MC-WFS or not. In the bad old MZ days, I remember that the MC mirror alignment would drastically change the post-MC RAM.

It requires another PD/demod set, but may be illuminating in the end. 

Also, can someone please add some channels to EPICS which calibrate the RAM channels into RAM units?

  6115   Wed Dec 14 01:35:06 2011 KojiUpdateIOOMC alignment craziness

~11PM I came to the 40m and found the MC is repeating "LOCK->WFS ON->UNLOCK" sequence for ~2hours.

I checked the WFS spots on the QPDs and aligned them. No luck. I suspected the clipping of the beam in the chamber.

After I checked the trends of MC SUS OSEM values and IPPOS, I concluded that the input beam was aligned to somewhat misaligned MC.

The most noticable thing was that IPPOS (X, Y) indicated about (-0.5, 0) although the recent trend shows (-1, -0.5) is nominal.
In fact, the beam was about dropping from the diode. In addition, I found that the MC2 suspension showed a jump in the morning at around 8.30AM.|
This is consistent with what Jenne described.

This was a difficult situation as everything was moved.
I used the OSEM values to come back to the previous alignment of the suspensions, and started touching Zig-Zag before the MC.
After the alignment I ended up more clipping of the MC REFL. Also the spot on the IPPOS QPD was more dropping.

So, I have empirically used MC3 to misalign in Yaw to have better spot position on IPPOS. Then, the Zig Zag was aligned.
Then the spot on MC2 was adjusted while MCTRANS was kept maximized.

This helped the things back in the normal state.

Now the WFS servo is happily controlling the alignment.
MC REFL is 4.8 and 0.47 for unlocked and locked. (MCREFL_UNLOCK was 4.6 before my touch)
MCTRANS is 27000, which is close to the nominal.
IPPOS total, x, and y are 0.36, -0.97, and -0.47, respectively. They are about the nominal.

~1AM done

HOWEVER, we still don't know the position of the spot on MC1/MC3, and ITMY and ETMY.
I should consult with Kiwamu to check the spot positions tomorrow.

General lessons:
- If you find any reduction of MC transmission, check the suspensions to see if there is any slip.
- Before touching the input optics to recover the MC alignment, we should think what was moved.
- Before touching EOM alignment you must check the MC alignment WITHOUT WFS, so that you can recover the misalignment of EOM by the Zig-Zag steering.
- WFS is sensitive to clipping of the beam.
- We need a nifty indicator to tell how the MC transmitted beam is good.

Attachment 1: Untitled.png
Untitled.png
  6116   Wed Dec 14 12:18:11 2011 ZachUpdateRF Systemheater reengaged

I reengaged the heater this morning, to compare it with the free-wafting and passive box-covered data. In order to make the loop stable, I had to reduce the gain of the AD620 by 10. I have increased the TEMP_MON preamp gain by 10, so the calibration should still be ~3.5 V/K into the ADC (and in DV).

Below is a screenshot showing that the RAMmon signals are pushed to some (nonzero) value, and it appears that they stay there despite the changing PSL table temperature as measured by FSS_RMTEMP. My post from last week shows that without the heater servo the temperature of the EOM can follows RMTEMP almost exactly. So, it seems like the heater is working well at low frequencies, modulo sensor noise, which ought to be low for the thermistor. Since several things (MC, etc.) have changed since out baseline data, it migth be prudent to let this sit for a little while and then disconnect the heater to see what happens.

heater_reengaged_12_14_11.png

  6118   Wed Dec 14 14:07:48 2011 KojiUpdateIOOMC alignment craziness

[Kiwamu Koji]

To check if the MC alignment is OK or not, we tried to lock the Y-arm.

Once the alignment of Y-arm was restored, we saw the resonant peak of ~0.2 in TRY.
After a small tweak of PZT2, TRY has got improved up to 0.7.

Kiwamu made a small tweak on the problematic PZT1, then the full (1.0) TRY was recovered.

Thus we concluded the current MC alignment is good enough.

  6119   Wed Dec 14 14:30:43 2011 JenneUpdateRF SystemLO for new demod box

The Rich demod box wants 10dBm for the local oscillator inputs, so I measured the values that we have coming out of the distribution box.  I'm using the "Spare 55MHz" and the "POP11" outputs, both of which had terminators so were not in use. 

The 55MHz had ~600mV peak, so between 5 and 6 dBm. 

The 11MHz had ~800mV peak, so about 8 dBm.

This is not enough dBm for either.  Going in search of RF amplifiers now...

  6120   Wed Dec 14 14:40:53 2011 steveUpdateGreen Lockingdelay line bnc cable specs

The existingly used used Pasternack Enterprices RG58 C/U cable lenght ~ 140 ft and the specs are here at Atm1

 

Atm2 The performance grade RG58-P coaxial cable specs.

Attachment 1: rg58cu.jpg
rg58cu.jpg
Attachment 2: RG58-P.pdf
RG58-P.pdf
  6121   Wed Dec 14 16:19:46 2011 ZachUpdateRF SystemLO for new demod box

I'm not sure I agree with your conversions, BUT:

The IQ boards use a PE4140, fancy MOSFET array as the mixer, and according to Peregrine (manufacturer), they can be operated with 0-20 dBm LO drive. I'm not recommending we drive them at 0 dBm, but perhaps the numbers you mentioned are OK.

Quote:

The Rich demod box wants 10dBm for the local oscillator inputs, so I measured the values that we have coming out of the distribution box.  I'm using the "Spare 55MHz" and the "POP11" outputs, both of which had terminators so were not in use. 

The 55MHz had ~600mV peak, so between 5 and 6 dBm. 

The 11MHz had ~800mV peak, so about 8 dBm.

This is not enough dBm for either.  Going in search of RF amplifiers now...

 

  6122   Wed Dec 14 18:06:39 2011 ZachUpdateRF SystemLO for new demod box

Actually, the LO inputs to the IQ boards have AP1053 (Cougar) amps on them. These are 10 dB amps and so putting 10 dBm in puts us on the very maximum of the LO range at 20 dBm.

I think the distribution box levels are fine. 

Quote:

I'm not sure I agree with your conversions, BUT:

The IQ boards use a PE4140, fancy MOSFET array as the mixer, and according to Peregrine (manufacturer), they can be operated with 0-20 dBm LO drive. I'm not recommending we drive them at 0 dBm, but perhaps the numbers you mentioned are OK.

Quote:

The Rich demod box wants 10dBm for the local oscillator inputs, so I measured the values that we have coming out of the distribution box.  I'm using the "Spare 55MHz" and the "POP11" outputs, both of which had terminators so were not in use. 

The 55MHz had ~600mV peak, so between 5 and 6 dBm. 

The 11MHz had ~800mV peak, so about 8 dBm.

This is not enough dBm for either.  Going in search of RF amplifiers now...

 

 

  6123   Wed Dec 14 19:59:12 2011 JenneUpdateRF SystemLO for new demod box

Quote:

Actually, the LO inputs to the IQ boards have AP1053 (Cougar) amps on them. These are 10 dB amps and so putting 10 dBm in puts us on the very maximum of the LO range at 20 dBm.

I think the distribution box levels are fine. 

Quote:

I'm not sure I agree with your conversions, BUT:

The IQ boards use a PE4140, fancy MOSFET array as the mixer, and according to Peregrine (manufacturer), they can be operated with 0-20 dBm LO drive. I'm not recommending we drive them at 0 dBm, but perhaps the numbers you mentioned are OK.

Quote:

The Rich demod box wants 10dBm for the local oscillator inputs, so I measured the values that we have coming out of the distribution box.  I'm using the "Spare 55MHz" and the "POP11" outputs, both of which had terminators so were not in use. 

The 55MHz had ~600mV peak, so between 5 and 6 dBm. 

The 11MHz had ~800mV peak, so about 8 dBm.

This is not enough dBm for either.  Going in search of RF amplifiers now...

 

 

 Yeah, I looked and saw that it's a semiconductor mixer, so it doesn't have to be as perfect. 

Everything is plugged in now to the new demod board.  More details soonly...

The I & Q outs are plugged into whitening filter #3, channels 5-8.  11MHz I = chan 5, 11MHz Q = chan 6, 55MHz I = chan 7, 55MHz Q = chan 8.  These channels are probably already recorded, but I haven't checked yet.  Hopefully I'll have time tonight after I pack for my trip.  But Zach, can you look into it tomorrow just to check??  Backup plan is to just go back to using the AS11 and POP55 boards and channels if the new board isn't doing what it's supposed to.

I disconnected the 3rd and 4th channels of the demod box since they were drawing unnecessary current, and making the box hot.  Now the box is just warmish.

  6124   Thu Dec 15 11:47:43 2011 jamieUpdateCDSRTS UPGRADE IN PROGRESS

I'm now in the middle of upgrading the RTS to version 2.4.

All RTS systems will be down until futher notice...

  6125   Thu Dec 15 22:22:18 2011 jamieUpdateCDSRTS upgrade aborted; restored to previous settings

Unfortunately, after working on it all day, I had to abort the upgrade and revert the system back to yesterday's state.

I think I got most of the upgrade working, but for some reason I could never get the new models to talk to the framebuilder.  Unfortunately, since the upgrade procedure isn't document anywhere, it was really a fly by the seat of my pants thing.  I got some help from Joe, which got me through one road block, but I ultimately got stumped.

I'll try to post a longer log later about what exactly I went through.

In any event, the system is back to the state is was in yesterday, and everything seems to be working.

  6126   Fri Dec 16 13:29:15 2011 kiwamuUpdateGreen LockingY arm noise budget : 60Hz line noise is killing us
Along with development of the automation script, my goals last night were :
 (1) Take a noise budget when the standard ALS configuration is applied
 (2) Take a beautiful time series to show how ALS brings the cavity to the resonance point
 
 However I gave up goal (2) because the resultant time series were very fluctuating at 60 Hz and it wasn't so beautiful enough.
As shown in the noise budget below, the 60 Hz line noise currently dominates the arm displacement.
 

Yarm_ALS_2011DEC16.png

       About Noise Budget       

 The spectra were taken when the arm length was kept at the resonance point using the ALS servo.
So the error signal was taken from the beat-note and was fed back to ETMY.
The servo UGF was at about 100 Hz and the fine frequency discriminator was used.
The red curve in the plot is the arm displacement observed by POY11, which is an out-of-loop sensor in this case.
From the plot it is apparent that the 60 Hz line noise raises the rms to few 100 pm level.
 

       How to improve it ?     

According to my quick calculation if we can exclude the 60 Hz line noise from the rms integration, the rms becomes about 70 pm, which is nice.
I somehow believe this line noise comes from the ALS servo and is injected to the coil-magnet actuator.
So I propose to lower the UGF and make it lower than 60 Hz such that
the servo doesn't react to the 60 Hz line noise and hence no 60 Hz noise injection to the arm displacement.
In any case lowering the UGF is better since our ALS sensor sees only noise above 40 Hz according to the previous noise measurement (#5970)
  6127   Sat Dec 17 00:00:03 2011 kiwamuUpdateGreen Locking60 Hz line nose gone

Quote from #6126
As shown in the noise budget below, the 60 Hz line noise currently dominates the arm displacement.

 The 60 Hz line noise has gone away.

It turned out that the line noise came from an oscilloscope.
The oscilloscope had been connected to a SR560, which amplifies the frequency-discriminated signal before the ADC as a whitening filter.
I still don't have a good explanation for it, but somehow connecting the oscilloscope made the line noise pretty high.
  6129   Sat Dec 17 03:59:32 2011 kiwamuUpdateSUSAborted Hysteresis test

Quote from #6128

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The hysteresis test has been aborted.

All of the suspensions have accumulated unexpectedly big DC biases of about 5 from their nominal points.

In fact the ITMX and ITMY mirrors started being stacked to their OSEMs.
The script process has been force-quit and I have restored all the DC biases to their nominal points.
They still look okay: MC can be locked at the 00 mode, DRMI fringe is visible at AS, the green beams are resonating the arm cavities
Need another trial.
  6130   Sat Dec 17 11:53:46 2011 ZachUpdateSUSAborted Hysteresis test

Do you guys have timestamps for when you started/ended the test? I have been trying to take some long-term RAM data but keep getting foiled by stuff (this test, RTS upgrade, switching of RAMmon channels, etc.)

Quote:

Quote from #6128

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The hysteresis test has been aborted.

All of the suspensions have accumulated unexpectedly big DC biases of about 5 from their nominal points.

In fact the ITMX and ITMY mirrors started being stacked to their OSEMs.
The script process has been force-quit and I have restored all the DC biases to their nominal points.
They still look okay: MC can be locked at the 00 mode, DRMI fringe is visible at AS, the green beams are resonating the arm cavities
Need another trial.

 

  6131   Sat Dec 17 12:41:46 2011 KojiUpdateSUSAborted Hysteresis test

The test was from: 2011-12-17 09:48 to 11:49 (UTC).
This corresponds to the period from 2011-12-17 01:48 to 3:49 (PST).

ZK: Thanks

ELOG V3.1.3-