We still think about the coherence between seismic noise and mode cleaner length. We beleive that
The 'helping' trick is a good one: we should use our best guess for the stackTF and the pendulumTF and put it into the IIR filter bank to pre-filter the seismometer signals before they get to the MC mirrors. Also should remember that the signal we send to suppress the seismic motion is applied to the pendulum as a force, not a displacement.
The 3 Hz fast cutoff in the MC_F signal is a good clue. It means that at low frequencies, perhaps the noise source is going through a digital 3 Hz elliptic or Chebychev filter.
I've looked through the coherence between the MC length and seismometers after the if-statement problem was fixed. Coherence improved for all seismometers but is still not 1. It is possible that contribution from X, Y, Z directions split the coherence between them but at ~0.2-03 Hz we do not see much coherence for all these directions.
I looked at the coherence between MC2 OSEM signal and MC_F when the AUTO LOCKER is ON and OFF. I thought that we'll ses the same coherence for both regimes as laser is locker to the MC length. However, I figured out the coherence is worse when AUTO LOCKER is ON at frequencies 0.2-0.3 Hz.
The first idea that comes to mind is that when feedback to the laser is provided, the pressure to the mirrors from the laser beam is changed.
I used the coh_carpet.m function from the mDV to calculate this plot:
coh_carpet('C1:PEM-ACC_MC1_X','C1:PEM-ACC_MC2_X',gps('now - 3 days'),3600*12,4,10,64)
It shows the coherence v. time of two of our X-direction accelerometers starting around 1AM on Friday and going for 12 hours.
I'm not sure what it means exactly, but it looks like the coherence is relatively steady as a function of time. I will need more RAM than Rosalba or a smarter code to calculate longer time stretches.
We've been talking about increasing the series resistance for the coil driver path for the test masses. One consequence of this will be that we have reduced actuation range.
This may not be a big deal since for almost all of the LSC loops, we currently operate with a limiter on the output of the control filter bank. The value of the limit varies, but to get an idea of what sort of "threshold" velocities we are looking at, I calculated this for our Finesse 400 arm cavities. The calculation is rather simplistic (see Attachment #1), but I think we can still draw some useful conclusions from it:
So, from this rough calculation, it seems like we would lose ~25% efficiency in locking the arm cavity if we up the series resistance from 400ohm to 1kohm. Doesn't seem like a big deal, becuase currently, the single arm locking
We have two cold cathode gauges at the pump spool and one signal cable to controller. CC1 in horizontal position and CC1 in vertical position.
CC1 h started not reading so I moved cable over to CC1 v
Our cold cathode 423 gauges are 10 years old. They get insulated by age and show no ionization current. We should replace them at the next vent. I'm buying 4 at $317ea
CC4 cold cathode gauge jump triggered interlock to close VM1 valve to protect the RGA.
The IFO pressure is 1e-5 Torr
Vac normal was recovered by opening VM1
The cold cathode gauge is back to normal. cc4 is the last gauge is "functioning"
MKS is not responding. The spare controller and gauges are back for repair.
The IFO pressure is estimated ~1E-6 Torr with modified Vac normal valve configuration.
CC4 is in a jumping mode between 2e-5 and 1e-6 Torr
Pressure based interlock kicks in to close VM1 at 2e-5 Torr to protect the RGA.
I did open VM1 repeatedly in the last few mornings but as cc4 jumps VM1 closes.
As VM1 closed to RGA scans are not seeing the IFO. I will look at some scans on Monday.
Mean while I opened VM2 to lower the pressure for the RGA. This change will be read by "Current Status: Undefined State"
So do not panic, the IFO pressure is normal.
I need someone's help to raise the interlock threshold to 5e-5 Torr
I'm buying a new cold cathode gauge on Monday.
note: cc1 is out of order!
just read P1 the pressure is < 7e-4 Torr This gauge is very reliable and it is at the low end of it's range.
A comparator has been installed before the MFDs (mixer-based frequency discriminator) to eliminate the effect from the amplitude fluctuation (i.e. intensity noise).
As a result we reached an rms displacement of 580 Hz or 80 pm.
As a result we reached an rms displacement of 580 Hz or 80 pm.
(differential noise measurement)
Here is the resultant plot of the usual differential noise measurement.
The measurement has been done when the both green and red lasers were locked to the X arm.
In the blue curve I used only MFD. In the black curve I used the combination of the comparator and the MFD.
Noise below 3 Hz become lower by a factor of about 4, resulting in a better rms integrated from 40 Hz.
Note that the blue and the black curve were taken while I kept the same lock.
A calibration was done by injecting a peak at 311 Hz with an amplitude of 200 cnt on the ETMX_SUS_POS path.
Yesterday Koji modified his comparator circuit such that we can take a signal after it goes thorough the comparator.
The function of this comparator is to convert a sinusoidal signal to a square wave signal so that the amplitude fluctuation doesn't affect the frequency detection in the MFD.
I installed it and put the beat-note signal to it. Then the output signal from the comparator box is connected to the MFDs.
The input power for the comparator circuit has been reduced to -5 dBm so that it doesn't exceeds the maximum power rate.
I have modified the code for frequency scanning and have made it completely command line enabled. The code is written in python. It is saved in the name "frequency_scanning_argparse.py". I have uploaded it to the Mode-Spectroscopy Github repository.
Inorder to use this code there are two ways.
1. We can mention the ' frequency' on which marconi need to work. Then it will change the marconi frequency to that perticular value.
eg: Type in the terminal as follows for changing the marconi frequency to 59 Mhz.
python frequency_scanning_argparse.py 59e6
2. Inorder to give a scan to the marconi frequency, provide the 'start frequency', 'end frequency' and the 'number of points' in between. This will be more conveniant when we want to run the scan in different ranges.
eg: Type in the terminal as follows for a start frequency of 59 Mhz, end frequency of 62MHz and number of points in between equal to 1000.
python frequency_scanning_argparse.py 59e6 62e6 1000
In both cases the code will show you the frequency of the marconi before we run this code and it will change the marconi frequency to the desired frequency.
Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.
It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.
Frequency response of the servo is taken from the document D040180. I assumed coupled cavity pole to be ~100 Hz.
The only question is if our EOM has enough range. Boost 2 increases noise injection by 10 dB in the frequency range 20-50 kHz. Boost 3 has even higher factor.
Once the control cable (bakplane cable) is identified, we can install the module to the LSC analog rack.
We should be able to test the CM servo with either POX or POY and only one correspoding arm without modifying the servo TF.
Just for this test, we don't need to use MCL.
These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?
We should be able to estimate the noise coming out of the MC using the single arm and then make a guess for the CM loop gain requirement. There's no reason to keep the old Boost shapes; those were used in the old MC configuration which had a RefCav. In addition to minimizing the EOM range, we should also minimize the AO signal as Koji has pointed out. In practice, I've seen that using ~300 Hz of offset makes no harm with 4 kHz MC pole.
Attached is matlab code that I used
% IMC OL
G = zpk(-2*pi*8964, 2*pi*[-10; -10; -10; -1000; -274000], db2mag(242.5)) * ...
tf([1 0.8*1.55e+05 3.1806e+10], 1);
% CARM PATH
CARM = G/(1+G);
% Common mode boosts
BOOST = zpk(-2*pi*4000, -2*pi*40, 1);
BOOST1 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST2 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST3 = zpk(-2*pi*4500, -2*pi*300, 1);
% Coupled cavity pole
CCPole = zpk(, -2*pi*100, 2*pi*100);
% Servo gain
Gain = db2mag(43);
% CARM OL with boosts
H = CARM * CCPole * BOOST * Gain;
H1 = H * BOOST1;
H2 = H1 * BOOST2;
H3 = H2 * BOOST3;
% bode(H, H1, H2, H3, 2*pi*logspace(3, 5, 10000));
% bode(1/(1+H), 1/(1+H1), 1/(1+H2), 1/(1+H3), 2*pi*logspace(3, 5, 10000));
We wish to study the coherence of the two NPROs i.e. PSL and the X-end-NPRO by locking both of them to the X-arm and then observing the green beat frequency fluctuations.
What we did:
a) locked the PSL to the X-arm as described in 4153
b) locked the x-end-NPRO to the X-arm with a PDH lock to the reflected green from the ETMX
c) Obtained the green beat signal with a spectrum analyser as described in 3771
Please see the attached screen shots from the spectrum analyser. They are taken with different BW and sweep range settings. They give a estimate of the width of the green beat signal and the range of the frequency fluctuations of the beat-note.
a) width of the beat note is less than 6KHz if measured over time scales of a few milli seconds
b) the frequency fluctuations of the beat note are about 100KHz over time scales longer than 100ms
We wish to record the beat note frequency as a function of time in order to establish the stability over time scale of a day.
Today we attempted to convert the beat-note frequency into an analog voltage using the SR620 frequency counter.
First an observation: the stability of the green beat was seen to be much better than the 100kHz fluctuation seen yesterday. Probably because Kiwamu noticed that one of the MC mirrors had a large variance in its motion and changed the gain and filter parameters to decrease this. The PSL was therefore more stable and the green peak fluctuation was less than 10kHz over time scales of a few seconds.
SR620 D/A output resolution given by the manufacturer is 5mV over the -10 to +10V range and this range corresponding to 300MHz. We, however saw fluctuations of 100mV on the screen which looked as if they corresponded to the least significant bit. This would imply a resolution of 1.5MHz at this range. Even if the manufacturer's claim was true it would lead to a resolution of 75kHz, far in excess of the required resolution a few hundred Hz.
We therefore require to set up the VCO-PLL to obtain a finer frequency resolution.
In the mean time the green beat drifted beyond the 100MHz detection band of the green-PD. So we changed the x-end-NPRO temperature by -0.05 to bring it back into the detection band.
We are also considering, Rana and Koji's suggestion of using a set of 14 flip-flops to divide the ~80MHz beat frequency so that it comes down to about 4kHz. This could then be sampled by the usual 16-bit, 64kSa/s ADC cards and brought into the digital domain where further digital processing would be needed to extract the the required frequency variations in the 0 to 10kHz band. Found a nice paper on this object
>> which decimate
Rack 1x6 is very noisy.
SunFire X4600 computer: FB (directly below Megatron) has it's yellow warning light on. It must be loosing one of it's fan bearings.
Jetstore's error message: IDE channel #2 reading error
It seems that the front fan unit was running at the full speed. The fan itself seems still OK.
I talked with Jamie and make a power cycling (i.e. shutdown gracefully, unplug the power supply cables (x4), plug them in again, and pushed the power button)
The warning signal went off and the fan is quiet. FOR NOW.
Now, daqd and ndsd is down.
FB cannot mount /opt/rtcds and /cvs/cds during its boot.
After mounting these manually, I tried to run /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab
but they don't keep running.
I'll be back to this issue tomorrow with Jamie's help.
All suspentions are kicked up. Sus dampings and oplev servos turned off.
c1iscey and c1lsc are down. c1asc and c1iovme are up-down
The computers and RFM network are up working again. A boot fest was necessary.Then I restored all the parameters with burtgooey.
The mode cleaner alignment is in a bad state. The autolocker can't get it locked. I don't know what caused it to move so far from the good state that it was till this afternoon. I went tuning the periscope but the cavity alignment is so bad that it's taking more time than expected. I'll continue working on that tomorrow morning.
I now suspect that after the reboot the MC mirrors didn't really go back to their original place even if the MC sliders were on the same positions as before.
we diagnosed the problem. It was related with sticky sliders. After a reboot of C1:IOO the actual output of the DAC does not correspond anymore to the values read on the sliders. In order to update the actual output it is necessary to do a change of the values of the sliders, i.e. jiggling a bit with them.
The PSL -leg concrete was sealed with a single coat of SCOFIELD Cureseal-S to minimize shedding of particles.
The optical table was covered and optics were removed from the shelf. Accelerometers were turned off.
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
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.
8 pieces of 10" CF blanks were shipped to MIT
It's just one of the stepping stones, but not yet a mile stone.
Keep going forward!
01:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 01)
Subsystem: Intel Corporation Unknown device 304a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 209
Region 0: Memory at ff8ff000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at bc00 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
One of the reasons that conlog seems so slow lately is that its been writing 100's of MB of .log files every day since early summer. It looks like the people who have been working on the mdl builds have not been properly adjusting the conlog channel lists. When this is not done conlog just gets filled up with non-control channels like OUT, OUTPUT, OUTMON, etc.
Peter Shawhan has supplied us with many scripts in the conlog directory to clean up these bloated files and fix the channel list.
I cleaned up a bunch of conlog stuff to make it all a little more sane and simple. I also fixed the messy startup shenanigans, so that it should now start up sanely and on it's own (using Ubuntu's native upstart system). The conlog wiki page was updated with all the new info.
By the way, I also did confirm that it is running and registering EPICS changes.
I restarted the conlogger on op340m. This needs to be done when op340m is rebooted--it wasn't done for some reason and so we've lost several days of controls records.
Added the conlog directory to the SVN, minus the enormous data directory. We are now free to make changes to the conlog code.
I added a cronjob on op340m to check every half-hour if the conlog is running, and if not, restart it.
The main page of connection error monitor can be a scheme of computers and models with connections. If there is an error in connection, the corresponding arrows turns from green to red.
Each arrow is a line to a more detailed information about the channels.
The 40m fenced area will start storing this large ~ 8000 lbs chamber on April 14. The asphalt will be cut, jack hammered the next 2-3 days in order to lay concrete.
Their schedule is from 8 to 5 starting tomorrow. We are asking them to work from 6 to 3pm
ETMX is about 12-15 ft away
8 days plot: Thurdsay, Friday, Sat and Sun without construction
The concrete floor cutting has begun next door at CES
ATM1: Seismometers are saturating, suspensions are OK
Atm2 : activity next door, diesel Backhoe and diesel concrete cutter are running
Atm3: CES exhaust fans output is pick up by 40M-Annex-North AC unit intake. The 40m office room has some diesel smell...........see # 2377
CES construction is progressing. The 40m suspensions are bearing well.
atm1, PEM vs sus plots of 120 days
atm2, big pool walls are in place, ~10 ft east of south arm
atm3, 10 ft east of ITMY
atm4, ~60 ft east of ITMY
atm5, cold weather effect of N2 evaporator tower
The PZT sweeps that we've been making to characterize the ALS-X laser should probably be discarded - the DFD was not setup correctly for this during the past few months.
Since the DFD only had a peak-peak range of ~5 MHz, whenever the beat frequency drifts out of the linear range (~2-3 MHz), the data would have an arbitrary gain. Since the drift was actually more like 50 MHz, it meant that the different parts of a single sweep could have some arbitrary gain and sign !!! This is not a good way to measure things.
I used an ezcaservo to keep the beat frequency fixed. The attacehed screenshot shows the command line. We read back the unwrapped beat frequency from the phase tracker, and feedback on the PSL's NPRO temperature. During this the lasers were not locked to any cavities (shutters closed, but servos not disabled).
For the purposes of this measurement, I reduced the CAL factor in the phase tracker screen so that the reported FINE_PHASE_OUT is actually in kHz, rather than Hz on this plot. So the green plot is moving by 10's of MHz. When the servo is engaged, you can see the SLOWDC doing some action. We think the calibration of that channel is ~1 GHz/V, so 0.1 SLOWDC Volts should be ~100 MHz. I think there's a factor of 2 missing here, but its close.
As you can see in the top plot, even with the frequency stabilized by this slow feedback (-1000 to -600 seconds), the I & Q outputs are going through multiple cycles, and so they are unusable for even a non serious measurement.
The only way forward is to use less of a delay in the DFD: I think Anchal has been busily installing this shorter cable (hopefully, its ~3-5 m long so that the linear range is more. I think a 10 m cable is too long.), and the sweeps taken later today should be more useful.
Chub wanted to get the correct part number for the replacement UPS batteries which necessitated opening up the UPS. To be cautious, all the workstations were shutdown at ~9:30am while the unit is pulled out and inspected. While looking at the UPS, we found that the insulation on the main power cord is damaged at both ends. Chub will post photos.
However, despite these precautions, rossa reports some error on boot up (not the same xdisp junk that happened before). pianosa and donatella came back up just fine. It is remotely accessible (ssh-able) though so maybe we can recover it...
please no one touch the UPS: last time it destroyed ROSSA. Please ask Chub to order the replacement batteries so we can do this in a controlled way (fully shutting down ALL workstations first). Last time we wasted 8 hours on ROSSA rebuilding
I booted Rossa in rescue mode; though I see no errors on bootup, I still see the same error ("a problem has occurred") after boot, and a prompt to logout. I powered rossa off/on (single short press of power button), no change.
Booting in debug mode, I see that the error occurs when mounting /cvs/cds, with the error
Which is odd, because when I boot in recovery mode, is mounts /cvs/cds successfully.
I booted in emergency mode by adding to the boot command
but didn't have the appropriate root password to troubleshoot further (the usual two didn't work).