40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 278 of 339 Not logged in
ID Date Author Type Category Subject
149   Fri Nov 30 19:46:58 2007 ranaConfigurationComputersEPICS Time Bad again
The time on the EPICS screens is off by 10 minutes again. Por Que?

Its because the ntpd on scipe25 wasn't restarted after the last boot. If someone
knows how to put the ntpd startup into that machine, please do so.

This time I started it up by just going sshing in as controls and then entering:

sudo /usr/sbin/ntpd -c /etc/ntp.conf

which runs it as root and points to the right file.

It takes a few minutes to get going because all of the martian machines have to first fail to
connect to the worldwide pool servers (e.g. 0.pool.ntp.org) before they move on and try linux1
which has a connection to the world. Once it gets it you'll see the time on the EPICS screens
freeze. It then waits until the ntp time catches up with its old, wrong time before updating
again.

According to the Wikipedia, this time is then good to 128 ms or less.
12172   Mon Jun 13 19:30:58 2016 AakashUpdateGeneralEPICS Installation | SURF 2016

About acquiring data: Initially I couldn't start with proper Acromag setup as the Raspberry pi had a faulty SD card slot. Then Gautam gave me a working pi on which I tried to install EPICS. I spent quite a time today but couldn't setup acromag over ethernet.  But, it would be great if we have a USB DAQ card. I have found a good one here http://www.mccdaq.com/PDFs/specs/USB-200-Series-data.pdf It costs around 106$including shipping (It comes with some free softwares for acquiring data) . Also, I know an another python based 12bit DAQ card (with an inbuilt constant current source) which is made by IUAC, Delhi and more information can be found here http://www.iuac.res.in/~elab/expeyes/Documents/eyesj-progman.pdf It costs around 60$ including shipping.

About temperature sensing: The RTD which I found on Omega's list is having a temperature resolution of 0.1 deg C. I have also asked them for the one with good resolution. Also according to their reply, they have not performed any noise characteristics study for those RTDs.

12176   Tue Jun 14 11:52:08 2016 JohannesUpdateGeneralEPICS Installation | SURF 2016

We generally want to keep the configuration of the 40m close to that of the LIGO sites, which is why we chose BusWorks, and it is also being established as a standard in other labs on campus. Of course any suitable DAQ system can do the job, but to stay relevant we generally try to avoid patchwork solutions when possible. Did you follow Aidan's instructions to the book? I haven't set up a system myself, yet, so I cannot say how difficult this is. If it just won't work with the Raspberry Pi, you could still try using a traditional computer.

Alternatively, following Jamie's suggestions, I'm currently looking into using python for the modbus communications (there seem to be at least a few python packages that can do this), which would reportedly make the interfacing and integration a lot easier. I'll let you know when I make any progress on this.

 Quote: About acquiring data: Initially I couldn't start with proper Acromag setup as the Raspberry pi had a faulty SD card slot. Then Gautam gave me a working pi on which I tried to install EPICS. I spent quite a time today but couldn't setup acromag over ethernet.  But, it would be great if we have a USB DAQ card. I have found a good one here http://www.mccdaq.com/PDFs/specs/USB-200-Series-data.pdf It costs around 106$including shipping (It comes with some free softwares for acquiring data) . Also, I know an another python based 12bit DAQ card (with an inbuilt constant current source) which is made by IUAC, Delhi and more information can be found here http://www.iuac.res.in/~elab/expeyes/Documents/eyesj-progman.pdf It costs around 60$ including shipping. About temperature sensing: The RTD which I found on Omega's list is having a temperature resolution of 0.1 deg C. I have also asked them for the one with good resolution. Also according to their reply, they have not performed any noise characteristics study for those RTDs.

12610   Thu Nov 10 19:02:03 2016 gautamUpdateCDSEPICS Freezes are back

I've been noticing over the last couple of days that the EPICS freezes are occurring more frequently again. Attached is an instance of StripTool traces flatlining. Not sure what has changed recently in terms of the network to cause the return of this problem... Also, they don't occur coincidentally on multiple workstations, but they do pop up in both pianosa and rossa.

Not sure if it is related, but we have had multiple slow machine crashes today as well. Specifically, I had to power cycle C1PSL, C1SUSAUX, C1AUX, C1AUXEX, C1IOOL0 at some point today

Attachment 1: epicsFreezesBack.png
961   Thu Sep 18 01:14:23 2008 robSummaryComputersEPICS BAD

Somehow the EPICS system got hosed tonight. We're pretty much dead in the water till we can get it sorted.

The alignment scripts were not working: the SUS_[opt]_[dof]_COMM CA clients were having consistent network failures.
I figured it might be related to the network work going on recently--I tried rebooting the c1susaux (the EPICS VME
processor in 1Y5 which controls all the vertex angle biases and watchdogs). This machine didn't come back after
multiple attempts at keying the crate and pressing the reset button. All the other cards in the crate are displaying
red FAIL lights. The MEDM screens which show channels from this processor are white. It appears that the default
watchdog switch position is OFF, so the suspensions are not receiving any control signals. I've left the damping loops
off for now. I'm not sure what's going on, as there's no way to plug in a monitor and see why the processor is not coming up.

A bit later, the c1psl also stopped communicating with MEDM, so all the screens with PSL controls are also white. I didn't try
rebooting that one, so all the switches are still in their nominal state.
963   Thu Sep 18 12:16:01 2008 YoichiUpdateComputersEPICS BACK

 Quote: Somehow the EPICS system got hosed tonight. We're pretty much dead in the water till we can get it sorted.

The problem was caused by the installation of a DNS server into linux1 by Joe.
Joe removed /etc/hosts file after running the DNS server (bind). This somehow prevented proper boot of
frontend computers.
Joe and I confirmed that putting back /etc/hosts file resolved the problem.
Right now, the DNS server is also running on linux1.

We are not sure why /etc/hosts file is still necessary. My guess is that the NFS server somehow reads /etc/hosts
when he decides which computer to allow mounting. We will check this later.

Anyway, now the computers are mostly running fine. The X-arm locks.
The Y-arm doesn't, because one of the digital filters for the Y-arm lock fails to be loaded to the frontend.
I'm working on it now.
964   Thu Sep 18 13:05:05 2008 YoichiUpdateComputersEPICS BACK

 Quote: The Y-arm doesn't, because one of the digital filters for the Y-arm lock fails to be loaded to the frontend. I'm working on it now.

Rob told me that the filter "3^2:20^2" is switched on/off dynamically by the front end code for the LSC.
Therefore, the failure to manually load it was not actually a problem.
The Y-arm did not lock just because the alignment was bad.
Now the Y-arm alignment is ok and the arm locks.
2690   Sun Mar 21 20:08:20 2010 kiwamu, ranaUpdatePSLEOM wasit size

We are going to set the waist size to 0.1 mm for the beam going through the triple resonant EOM on a new PSL setup.

When we were drawing a new PSL diagram, we just needed to know the waist size at the EOM in order to think about mode matching.

This figure shows the relation between the waist size and the spot size at the aperture of the EOM.

The x-axis is the waist size, the y-axis is the spot size. It is clear that there is a big clearance at 0.1 mm waist size. This is good.

Also it is good because the waist size is much above the damage threshold of the EO crystal (assuming 1W input).

The attached file is the python code for making this plot.

Attachment 2: waist.py.zip
2691   Sun Mar 21 21:02:39 2010 KojiUpdatePSLEOM waist size
You don't need a lengthy code for this. It is obvious that the spot size at the distance L is minimum when L =
zR, where zR is the Rayleigh range. That's all.

Then compare the spot size and the aperture size whether it is enough or not.

It is not your case, but if the damage is the matter, just escape to the large zR side. If that is not possible
because of the aperture size, your EOM is not adequate for your purpose.
4122   Fri Jan 7 00:14:36 2011 kiwamuUpdateIOOEOM triple resonant box is working

I checked the triple resonant box for the broadband EOM this afternoon, and found it was healthy.

So I installed it again together with a power combiner and succeeded in locking the MC.

Since the box has a non-50 Ohm input impedance at 29.5 MHz, so it maybe needed to adjust the phase of the LO for the demodulation of the PDH signal.

A good thing is that now we are able to impose the other sidebands (i.e. 11 MHz and 55MHz) via the power combiner.

5984   Wed Nov 23 00:30:14 2011 ZachUpdateRF SystemEOM temperature controller trials

[Jenne, Zach]

We did some testing of the prototype temperature controller. When I left it late last night, it was not working in conjunction with the real heater and PT100 mounted to the EOM, but had been tested using simulated loads (a spare heater and a potentiometer for the RTD).

We measured each of the reference resistors carefully, as I should have done in the first place since they are only 1% tolerance (I am using 100-ohm ones in series with ~15-ohm ones, so they have a variation of +/- an ohm or so, which is consequential). We calculated the estimated zero-signal resistance of the RTD, then used a trimpot to verify that the AD620 output behaved as expected. We realized that I didn't tie the 620's reference to ground, so the output was floating around by a lot. Once we did that, the readout was still not working properly, but eventually magic happened and we got an appropriate signal. I did find that there was a discrepancy between the estimated zero-signal resistance and that measured across the trimpot with the readout nulled---this may be caused by a small offset in the 620, but is not important so long as the output still scales properly.

Before trying it out again on the real McCoy, I tested the whole, closed-loop circuit with the spare EOM on Jenne's desk. The temperature oscillated at first, but a reduction of gain at the input stage of the driver allowed it to stabilize. The temperature of the EOM (sitting on the electronics bench) was kept constant with a control current that varied from ~40 - 70 mA, depending on how many people were around it, etc. This is pretty much perfect for the quiescent level, but that means that we might have to increase the baseline operating resistance of the PT100 (by changing the reference resistors) once it is sitting in a hot foam box. Otherwise, we will have no gain on the cooling side. I tested the circuit response by cupping my hands over the EOM to increase the temperature and ensuring that the current dropped so as to null the error signal. It worked pretty well, with a thermally-limited bandwidth of I would estimate around 0.1 Hz.

I went to try it out on the PSL table, but again it didn't work. It turned out that this time I had broken one of the soldered connections from the broken-out D-sub cable to the (tiny) wires going to the PT100, so there was no temperature signal. I resoldered it, but I forgot that there is a thin insulating layer on the wire, so no connection was made. Frank tutored Jenne on how to properly strip these wires without damaging the core, but alas I didn't pay attention.

The RTD/heater/D-sub package lies in wait on Jenne's desk, where I have left an apologetic note. Once it is fixed, we should be able to finally hook it up for realz.

6025   Mon Nov 28 15:43:36 2011 steveUpdateRF SystemEOM temp zoomed

Quote:

 Quote: Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome.

Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.

It is not working

Attachment 1: eomtempmon.png
6035   Tue Nov 29 14:22:03 2011 ZachUpdateRF SystemEOM temp stabilization performance

I left the EOM stabilization running overnight, so we can finally see how the EOM temperature stabilization does over long periods of time.

Here are both long-term (~13-hr) and short-term (1-hr) trends of the EOM temperature and the heater drive level. From the long trend you can see that the heater departed the steady value of ~7.8V that I observed last night to accommodate the diurnal heating of the lab in the morning---the temperature was held near zero offset.

From the short-term trend, there are 2 things to notice:

1. We are still very close to the digitization noise level for both signals. This is bad, because we want to look at the residual noise level, etc.
2. There appears to be some strange sort of disturbance of f~0.01-0.02 Hz. I'm not sure what causes the strange shape

Finally, here is a trend over the last ~24 hours of the EOM temperature, heater drive level, and the 11- and 55-MHz Stochmon signals. I believe that the abrupt shelves noticeable on the Stochmon trends are when c1sus was turned on and shut down, respectively (I'm not sure why that causes the signals to die, but the times seem right, and nothing obvious happens to the EOM temp stabilization signals at either time). The controller was turned on at ~8:40 UTC, and you can see that the Stochmon signals quiet down a lot right at that time. There is some residual drift (common-mode to both RF frequencies), which is most likely caused by a drift in some other parameter (e.g. laser frequency or power).

I took some relatively inconclusive power spectra and coherence measurements, but I'd rather wait until we have an uncontrolled data stretch with which to compare. I think what we should do now is disconnect the controller and then let it sit for a while.

6036   Tue Nov 29 15:25:29 2011 steveUpdateRF SystemEOM temp stabilization performance

It is not obvious what is working.

Attachment 1: 2days.png
6040   Tue Nov 29 18:17:27 2011 ZachUpdateRF SystemEOM temp stabilization performance

 Quote: It is not obvious what is working.

It should be. As I mentioned, you can only trust the Stochmon signals between 0840 and 1130 UTC; before this time, the temperature controller was not connected, and after this time, c1sus is shut down and the MC is not locked, as you can see in your DV plot.

Within this time frame, the Stochmon signals are relatively stabilized (though there is some residual common-mode-ish drift since we are not using RFAM as the error signal---i.e., other things like laser power and frequency can mix in). Also, anytime after 0840, the controller signals behave as they should (these are unaffected by the status of c1sus):

• The EOM temperature signal (error signal) is stabilized to a value very near zero
• The heater drive signal (control signal) moves around in such a way as to null the error signal, and you can confirm that it looks roughly like the opposite of the FSS_RMTEMP signal, as it should.

I am concerned with the other issues that I mentioned in my previous post, namely:

1. Error signal dominated by digitization noise above some low frequency despite 100x amplification
2. Strange ~0.01-Hz level disturbances in error signal.
6053   Wed Nov 30 13:52:09 2011 ZachUpdateRF SystemEOM temp stabilization ineffectual

This recent off/on run proved what I was afraid of: the temperature stabilization setup appears to do nothing except very near DC. The plot that Kiwamu posted is misleading because the "uncontrolled" data stretch at the beginning actually had the heater injecting random noise (since the circuit was broken). Below are some plots (sorry in advance for their crappiness---the plot tools wouldn't let me print to file for some reason):

Time series of the temp monitor, the heater monitor, and the 11- and 55-MHz RFAM monitors. The heater was disconnected at ~2:20 UTC, and the temperature is seen to equalize to the surroundings (note that the TEMP_MON is inverted, so positive change means decreasing temperature). The heater was reconnected by Kiwamu around 10:40 UTC, and you can see the temperature being driven back to the zero point by the loop. Note that the temperature was still decreasing at a fair rate when the heater is re-engaged---this could mean that we really need to take longer samples.

Spectra and coherence of the 11- and 55-MHz RFAM monitors before and after the control was re-engaged. It appears that the 11-MHz signal is unaffected while the 55-MHz signal actually gets worse. This also seems evident from the noisiness in the time series for that signal above (top right). Bad, bad, bad.

Spectrum of the EOM temperature signal before and after control was re-engaged. There seems to be no change whatsoever. Of course, as mentioned before, this signal seems to be close to the digitization noise level as seen in DV. I am not sure what the ADC noise looks like at these low frequencies. In case someone knows, the magnitude of this signal in counts is ~0.1 ct/rHz at 10 mHz; is this too low? Another thing to note is that the noise level in K is pretty low! I would be surprised if the RTD can really see 10 uK/rHz at and below 10 mHz.

I need to try and increase the gain of the servo to see if I can get it much higher without it becoming unstable.

6032   Tue Nov 29 02:09:15 2011 ZachUpdateRF SystemEOM temp stabilization fixed

I inspected the temperature stabilization circuit today to see why it wasn't working. It didn't make sense that it just kept railing the heater even though the error signal was negative (which should turn the heater current OFF).

It turns out that the LF356 (FET-input op amp) that serves as the filter stage for the heater driver was broken---I measured a full, railed positive output even though the input was negative. We didn't have any more LF356s, so I replaced it with an OPA604 (Burr-Brown FET-input), and all seemed to work fine.

Since we were having too much digitization noise, I also added a temperature monitor buffer using a non-inverting OP27 circuit with G=99. This makes the overall calibration ~7.6 V/K into the ADC.

Below is a time series showing that it is working. The circuit was turned on near the beginning, and you can see that the heater is railed at +10V until shortly after the error signal goes negative, at which point it adjusts and ultimately approaches a steady-state value of ~7.8V.

I have no figures to demonstrate this, but it seems that even with this 100x increase in monitor gain, the error signal is still below the ADC noise level. This could be because the ambient temperature fluctuations are just that small on timescales of less than a few hours. I'm not sure if we really need to be able to see the temperature noise level above a few mHz, but if we do we will have to find some way to increase our dynamic readout range.

Also, Koji told me where he stashed the nice protoboards, so I will get onto transferring this circuit onto one ASAP. Since it is working now, I think I'll leave it until after the TAC.

6056   Thu Dec 1 01:24:56 2011 JenneUpdateRF SystemEOM temp stabilization at PSL lab

[Frank, Jenne]

Activities in a far, far away land called PSL lab...

We are looking at the RFAM from the detuned ACAV refl pd in the red trace.  Red trace is the demodulated RFAM output.  RCAV was locked, so on a ~min time scale the freq drift follows, so we stay detuned.

Heater and temp sensor are taped to EOM, no foam box.

Around when the red trace starts, we turn on the heater to stabilize the temp.  After a while we reach the set point (no longer railing the heater), and start seeing temp stabilization.  The RFAM fluctuations clearly go down.  Neato.

No calibrations, no RIN, no nothing.  Get over it.

Green trace is the DC level of a different PD, which should also be sensitive to RFAM.

This is using a fancy-pants temp controller chip that Frank found.  It works, so that's handy.

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

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.

6022   Mon Nov 28 14:27:35 2011 JenneUpdateRF SystemEOM temp driver

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome.

Attachment 1: EOM_temp_driver_3days.png
6023   Mon Nov 28 14:40:43 2011 KojiUpdateRF SystemEOM temp driver

 Quote: Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome.

Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.

5391   Mon Sep 12 23:54:10 2011 kiwamuUpdateIOOEOM resonant box installed

[Mirko / Kiwamu]

The resonant box has been installed together with a 3 dB attenuator.

The demodulation phase of the MC lock was readjusted and the MC is now happily locked.

(Background)

We needed more modulation depth on each modulation frequency and so for the reason we installed the resonant box to amplify the signal levels.

Since the resonant box isn't impedance matched well, the box creates some amount of the RF reflections (#5339).

In order to reduce somewhat of the RF reflection we decided to put a 3 dB attenuator in between the generation box and the resonant box.

(what we did)

+ attached the resonant box directly to the EOM input with a short SMA connector.

+ put stacked black plates underneath the resonant box to support the wight of the box and to relief the strain on the cable between the EOM and the box.

+ put a 3 dB attenuator just after the RF power combiner to reduce RF reflections.

+ readjusted the demodulation phase of the MC lock.

The demodulation phase was readjusted by adding more cable length in the local oscillator line.

After some iterations an additional cable length of about 30 cm was inserted to maximize the Q-phase signal.

So for the MC lock we are using the Q signal, which is the same as it had been before.

Before the installation of the resonant box, the amplitude of the MC PDH signal was measured in the demodulation board's monitor pins.

The amplitude was about 500 mV in peak-peak (see the attached pictures of the I-Q projection in an oscilloscope). Then after the installation the amplitude decreased to 400 mV in peak-peak.

Therefore the amplitude of the PDH signal decreased by 20 %, which is not as bad as I expected since the previous measurement indicated 40 % reduction (#2586).

Attachment 1: EOM.png
Attachment 2: before.png
Attachment 3: after.png
Draft   Wed Nov 6 20:34:08 2019 KojiUpdateIOOEOM resonant box installed

 Quote: [Mirko / Kiwamu]  The resonant box has been installed together with a 3 dB attenuator. The demodulation phase of the MC lock was readjusted and the MC is now happily locked.   (Background) We needed more modulation depth on each modulation frequency and so for the reason we installed the resonant box to amplify the signal levels. Since the resonant box isn't impedance matched well, the box creates some amount of the RF reflections (#5339). In order to reduce somewhat of the RF reflection we decided to put a 3 dB attenuator in between the generation box and the resonant box.   (what we did)  + attached the resonant box directly to the EOM input with a short SMA connector.  + put stacked black plates underneath the resonant box to support the wight of the box and to relief the strain on the cable between the EOM and the box.  + put a 3 dB attenuator just after the RF power combiner to reduce RF reflections.  + readjusted the demodulation phase of the MC lock.   (Adjustment of MC demodulation phase)  The demodulation phase was readjusted by adding more cable length in the local oscillator line. After some iterations an additional cable length of about 30 cm was inserted to maximize the Q-phase signal. So for the MC lock we are using the Q signal, which is the same as it had been before.    Before the installation of the resonant box, the amplitude of the MC PDH signal was measured in the demodulation board's monitor pins. The amplitude was about 500 mV in peak-peak (see the attached pictures of the I-Q projection in an oscilloscope). Then after the installation the amplitude decreased to 400 mV in peak-peak. Therefore the amplitude of the PDH signal decreased by 20 %, which is not as bad as I expected since the previous measurement indicated 40 % reduction (#2586).

6073   Mon Dec 5 19:38:38 2011 JenneUpdateRF SystemEOM mount getting closer....

I have drilled all the holes necessary, and have tapped all but 4 of the holes for the new EOM mount.  The adapter plate is finished and ready to go (including a 10-min iso sonic bath).  The riser that goes between the table and the 9082 mount is drilled but not yet tapped.

14144   Tue Aug 7 23:06:30 2018 KojiUpdatePSLEOM measuement preparation

I was preparing for the aLIGO EOM measuement to be carried out tomorrow afternoon.

I did a few modifications to the PLL setup.

• The freq mixier in the PLL setup was replaced with ZP3 (level 7) from ZAD-6
• The PLL gain was reduced from 3.10 to 2.80 to prevent servo oscillation
• The main PSL marconi is connected to the PLL mixier and providing fixed 200MHz 8dBm.
• The main PSL modulation is off.

Tomorrow I am going to modulate the EOM with the AUX Marconi via an amplifier (probably)

Automated scripts (AGinit.py and AGmeas.py) are in /users/koji/scripts

I will revert the setup once the measurement is done tomorrow.

14145   Wed Aug 8 20:56:11 2018 KojiUpdatePSLEOM measuement preparation

Rich and I worked on the EOM measurement. After the measurement, the setup was reverted to the nominal state

• AUX PLL mixer was restored to ZAD-6
• The PLL gain was restored to 3.10
• The main PSL marconi is connected to the freq generator again. Using the beat note, I've confirmed that the modulations are applied on the beam.
• The PSL HEPA was reduced from 100 to 30.
6043   Tue Nov 29 19:08:53 2011 ZachUpdateRF SystemEOM heater disconnected

I disconnected the heater at ~2:20 UTC, leaving the sensor circuit operational. Don't be fooled by the apparent railing of the heater in the monitor trace below---the heater has been physically disconnected, so there is no current flowing even though the servo is railed (since the error signal is huge with the loop open).

Kiwamu and I also restarted c1sus and locked the MC so that we can get some uncontrolled Stochmon data. I think he is planning to reconnect the heater some hours from now so that we can get yet another controlled data stretch (since the first one was cut short by c1sus's going down).

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.

1095   Mon Oct 27 14:48:27 2008 YoichiConfigurationPSLEO shutter installed to the reference cavity
I'm now preparing for cavity ring down measurements of the reference cavity.
An EOM for polarization rotation is installed between the two steering mirrors for the reference cavity.
The location is before the polarized beam splitter (used to pick-up the reflected light from the cavity) and
after the half-wave plate. So we should be able to use the PBS as a polarizer.
While setting up the high voltage pulse generator, I realized that we don't have enough cables for it.
It uses special kind of connectors (Kings 1065-N) for HV connections. We need three of those but I could find
only two. I asked Bob to order a new connector.

For the moment, the EOM is left in the beam path of the reference cavity until the connectors arrive (Wed. or Thu. this week)
and the measurements are done.
The EOM distorts the beam and degrades the mode matching to the reference cavity.
I optimized the alignment of the crystal so that the RC transmission is maximum.
Even though, the transmission of the reference cavity is down from 2.8 (without EOM) to 1.7 (with EOM).
I increased the common gain of the FSS from 7dB to 10dB to compensate for this.
The mode clearner locks with this configuration.

If the EOM is really disturbing, one can just take it out.
Since I did not touch the steering mirrors, the alignment to the reference cavity should be recovered immediately.
12744   Fri Jan 20 17:12:37 2017 SteveUpdatePEMEM172 mic is hooked up in the PSL

Gautam and Steve,

It is hanging in the midle of the PSL enclosure. Wired to 1X1 to get plus and minus 15V through fuse.    It's output is connected to FB c17 input.

GV: C17 corresponds to "MIC 1" in the PEM model. So the output is saved as "C1:PEM-MIC_1_OUT_DQ"

 Quote: I added an EM172 to my soldered circuit and it seems to be working so far. I have taken a spectra using the EM172 in ambient noise in the control room as well as in white noise from Audacity. My computer's speakers are not very good so the white noise results aren't great but this was mainly to confirm that the microphone is actually working. white_v_ambient.pdf

Attachment 1: EM172c.jpg
12789   Thu Feb 2 17:34:25 2017 ranaUpdatePEMEM172 mic is hooked up in the PSL

I don't know if anyone looked at the time series (not trend) or spectrum of the Microphone after installation, but it looks bad and featureless to me. Is the Microphone broken?

This shows the spectrum from early this morning and again from tonight. You can see that it is bi-stable in its noise properties. This thing is busted; we're now removing it from the PSL so that it doesn' light it self on fire.

Attachment 1: MicFail.pdf
12790   Thu Feb 2 17:43:20 2017 gautamUpdatePEMEM172 mic is hooked up in the PSL

I had noticed something wonky with the microphone, but neglected to elog it. I had tested it after installation by playing a sine wave from my laptop and looking at the signal on the PSL table, it worked fine. But you can see in the attached minute trend plot that the signal characteristics changed abruptly ~half a day after installation, and never quite recovered.\

Attachment 1: Mic_broken.png
12222   Tue Jun 28 17:11:27 2016 PrafulUpdateGeneralEM172 Microphones

Found 60 EM172 microphones. Previous elog with details: 7777.

12344   Wed Jul 27 22:42:00 2016 PrafulUpdateElectronicsEM172 Amplifier

I recreated Den's microphone amplifier circuit on a solderless breadboard to test it and make sure it does what it's supposed to. So far it seems like everything is working- I'll do some testing tomorrow to see what the amplified output is like for some test noises. Here's the circuit diagram that Den made (his elog as well https://nodus.ligo.caltech.edu:8081/40m/6651):

I'm not sure why he set up the circuit the way he did- he has pin 7 grounded and pin 4 going to +12V while in the datasheet for the opamp (http://cds.linear.com/docs/en/datasheet/1677fa.pdf), pin 7 goes to positive voltage and pin 4 goes to negative voltage. There's some other strange things about the circuit that I don't really understand, such as the motivation for using no negative voltage source, but for now I'm going to stick with Den's design and then make some modifications after I have things working and a better understanding of the problem.

Here's my current plan:

-Make sure Den's amplifier works, test it out and make changes if necessary

-Make multiple amplifier circuits on soldering breadboard

-Either make a new amplifier box or reuse Den's old box depending on how many changes I make to the original circuit

-Solder EM172s to BNC connectors, set them up around the floor suspended

-Get the amplifier box hooked up, set up some data channels for the acoustic noise

-Add new acoustic noise tab to the summary pages

Den also mentioned that he wanted me to measure the coupling of acoustic noise to DARM.

6593   Wed May 2 19:47:20 2012 DenUpdatePEMEM 172 nonlinearities

I've checked new small EM172 microphones for nonlinearities using Koji's Mac Book speakers. EM172 + Mac nonlinearities are presented at the figure

The Mac's sound frequency was specified to be 500 Hz. Harmonics are seen at 1k, 1.5k, but their amplitude is ~30 times less.

7777   Mon Dec 3 16:37:09 2012 SteveUpdatePEMEM 172 microphones ordered

 Quote: I've put EM 172 microphones inside Steve's isolation box to measure their noise. I've attached mics to each other and aligned them using the tape. At low frequencies (below 1 Hz) the noise is limited by ADC as there is a 10 Hz high-pass filter inside mic readout box. ADC noise is measured by splitting the signal from 1 mic into 2 ADC channels.

BT EM172 microphones  are ordered.

7226   Sat Aug 18 19:29:56 2012 DenUpdatePEMEM 172 microphones noise

I've put EM 172 microphones inside Steve's isolation box to measure their noise. I've attached mics to each other and aligned them using the tape.

At low frequencies (below 1 Hz) the noise is limited by ADC as there is a 10 Hz high-pass filter inside mic readout box.

ADC noise is measured by splitting the signal from 1 mic into 2 ADC channels.

6594   Wed May 2 21:04:06 2012 DenUpdatePEMEM 172 coherence

I measured coherence between 2 EM 172 microphones in a "quiet room" with SR785

High-frequency noise (>2k) is SR785 noise - I'm not using any amplifier now, the signal from microphone is sent directly to SR785 and is weak at high frequencies.

11002   Wed Feb 11 16:49:41 2015 ranaUpdateelogELOGD restarted

No elog response from outside and no elogd process on nodus, so I restarted it using 'start-elog.csh'.

2518   Sun Jan 17 05:22:42 2010 ranaConfigurationComputersELOG script change

With Dave Barker's help, I changed the elog startup script. Instead of running as a Daemon with the -D option,

it now runs in the background with the unix "&". I think that the stdout and stderr are now redirected to a log file called elog.log.

We can 'tail -f' this file to see what its up to and debug any future crashing.

4121   Thu Jan 6 10:47:11 2011 KojiUpdateelogELOG fixed (re: restarted)

### Fixed the 40m elog crashing with the threaded display.

This morning I found that Google bot crashed the elog again. I started the investigation and found the threaded mode is fine if we use the recent 10 entries.

I gradually copied the old entries to a temporary elog and found that a deleted elog entry on August 6 had a corrupted remnant in the elog file. This kept crashed the threaded mode.

Once this entry has been eliminated again, the threaded mode got functional.

I hope this eliminates those frequent elog crashing.

Quote:

Google bot  crashed the elog again. Then, I found that Google bot (and I) can crash elogd by trying to show the threaded view.
There looks similar issue reported to the elog forum, the author did not think this is a true bag.

Note: This happens only for the 40m elog. The other elogs (ATF/PSL/TCS/SUS/Cryo) are OK for the threaded view.

 Quote: Did it again. It seemed that Google bot came to the elog and tried to obtain "http://nodus.ligo.caltech.edu:8080/robots.txt". That was the last of the log. Bot came from the AJW's homepage. Also Google FeedFecther came to the elog.

10405   Fri Aug 15 20:38:17 2014 ericqUpdateGeneralELOG dump

A few things that I have neglected to ELOG yet:

• scripts/offsets/LSCoffsets is a new script that uses ezcaservo to set FM offsets of our LSC PDs. It still warns about large changes, and lets you revert. It reads the FM gain to pick the right gain for the ezcaservo call.

• MC refl DC was all over the place today, and has recently been "fuzzier" on the wall StripTool than I like. I touched the MC2 pointing a little bit, and the WFS seemed to find a sweet spot where the refl got steady back at around and under 0.5. I then ran "offload WFS" to try and stay there.

• Incidentally, the PMC transmission drifted up to 0.81 at some point today. This is weird, since not too long ago, we were not able to reach this level even with careful alignment. This coincided with the MC power being back up to ~17k, and arms locking at around 0.95.

• Last week I quickly tried cranking up the x-end green modulation frequency to ~1.3MHz (corresponding to a notch in the PZT AM response), and using a 550k lowpass on the mixer output, instead of a 70k, to try to buy more phase and increase the UGF. It didn't work. I didn't have a way to tune the mixer phase angle, and the mixer output was super noisy, but there were instants where I could convince myself that a mode was briefly locked to the arm... I'm going to do the Right Thing and characterize the loop properly, to figure out how to get at least 10kHz of control bandwidth out of these things.

1119   Thu Nov 6 22:07:56 2008 ranaConfigurationComputersELOG compile on Solaris
From the ELOG web pages:

Solaris:

Martin Huber reports that under Solaris 7 the following command line is needed to compile elog:

gcc -L/usr/lib/ -ldl -lresolv -lm -ldl -lnsl -lsocket elogd.c -o elogd

With some combinations of Solaris servers and client-side browsers there have also been problems with ELOG's keep-alive feature. In such a case you need to add the "-k" flag to the elogd command line to turn keep-alives off.
10877   Thu Jan 8 03:40:50 2015 ericqUpdateComputer Scripts / ProgramsELOG 3.0

I've installed the very fresh ELOG 3.0, for nothing else than the new built in text editor which has a LATEX capable equation editor built right in.

Check out this sweet limerick:

$\int_{1}^{\sqrt[3]{3}}t^2 dt\, \textbf{cos}(\frac{3\pi}{9}) = \textbf{ln}(\sqrt[3]{e})$

10878   Thu Jan 8 09:24:40 2015 jamieUpdateComputer Scripts / ProgramsELOG 3.0
 Quote: I've installed the very fresh ELOG 3.0, for nothing else than the new built in text editor which has a LATEX capable equation editor built right in.  Check out this sweet limerick:  $\int_{1}^{\sqrt[3]{3}}t^2 dt\, \textbf{cos}(\frac{3\pi}{9}) = \textbf{ln}(\sqrt[3]{e})$

$\int \omega \epsilon \varepsilon \Gamma$

3784   Tue Oct 26 10:50:08 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5 -> ELOG 2.8.0

ELOG restarted with 2.8.0 again.

- moved elog-2.8.0/script dir to elog-2.8.0/script.orig

- copied elog-2.7.5/script to elog-2.8.0/script

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.8.0

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.8.0

- logbooks on 25th and 26th were copied from 2.7.5 to 2.8.0.

3780   Mon Oct 25 23:59:37 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

ELOG reverted to 2.7.5 due to editing difficulties

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5

- logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

3783   Tue Oct 26 07:02:05 2010 AlbertoConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

 Quote: ELOG reverted to 2.7.5 due to editing difficulties - /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5 - /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5 - logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

I think I had the same problem when I switched to 2.75 from 2.65.

Then the problem was FCKeditor.

We should try the solution I put in the elog page of the wiki.

3772   Sun Oct 24 19:23:41 2010 ranaConfigurationelogELOG 2.8.0
I stopped the ELOG and restarted us on 2.8.0.

To make sure nothing got lost, I killed the old process, copied over the logbooks/, themes/, and elogd.cfg to the new 2.8.0/ directory before starting the new Daemon.