We have to change the sample rate and AA filter for the mic channels before going too far with the circuit design.
To save the mic channels at higher than 2k (which we should do), we either have to move them to a different model, change the rate of the PEM model, or see if you can save data faster than the model runs (which I can't imagine is possible).
PEM model is running at 64K now. It turned out to be tricky to increase the rate:
We should also increase cut off frequency of the low-pass filter in the microphone pre-amplifier from 2 kHz up to ~20-30 kHz.
Thank you for changing the sample rate!
Also we have to change the Anti-Aliasing filter, as Jamie said.
Now my question is, whether S/N ratio is enough at high frequencies or not. The quality of EM172 microphone is good according to the data sheet. But as you can see in previous picture, the S/N ratio around 1kHz is not so good, though we can see some peaks, e.g. the sound that a fan will make. I have to check it later.
And, is it possible to do online adaptive noise cancellation with a high sampling rate such that computationally expensive algorithms cannot be run?
That's no good - we need BLRMS channels for many PEM channels, not just two. And the channel names should have the same name as they had in the past so that we can look at long term BLRMS trends.
C1PEM model is back to 2K.
We created a new C1MIC model for microphones that will run at 32K. C1SUS machine is full, we have to think about rearrangement.
For now, we created DQ channels for microphones inside iop model, so we can subtract noise offline.
We provided 0-25 kHz bandwidth noise to AA board and saw the same signal in the output of ADC in the corresponding channel. So cut-off frequency is higher then 25 kHz. There is a label on the AA board that all filters are removed. What does this mean?
We've turned off AA bench power supply, prepare to use fused from 1U.
Tonight I wanted to measure the ambient noise level using Blue Bird mics and figure out if Panasonic WM61a or Primo EM172/173 will be good enough or not. Blue Bird that is in the control room does not seem to work. May be the problem is with the pre-amplifier. The output measured by ADC/Oscilloscope is noise ( amplitude=5mV ). I will return to this issue tomorrow.
I've installed Blue Bird microphone to listen to the acoustic noise at the PSL near PMC.
Coherence between MC_F and Blue Bird output (C1:PEM-ACC_MC2_Z for now) is changing from low to high value at frequencies 20 - 200 Hz with period ~1 min. Maybe HEPA works with some periodicity. Now it works pretty hard, ~80% of max.
I've soldered EM172 microphones to BNC connectors to get data from them.
Then I've build an amplifier for them. The circuit is
I've build 6 such circuits inside 1 box. It needs +15 V to A3 and GND to A2. A1 power channel is not used.
LISO model for this scheme was created and simulation results were compared to measurement of each channel
Measured noise curve (green) is the SR785 own noise.
Last night Rana noticed that the overflows on the ITM and ETM coils were a crazy huge number. Today I rebooted c1dcuepics, c1iovme, c1sosvme, c1susvme1 and c1susvme2 (in that order). Rob helped me burt restore losepics and iscepics, which needs to be done whenever you reboot the epics computer.
Unfortunately this didn't help the overflow problem at all. I don't know what to do about that.
Just start by re-setting them to zero. Then you have to figure out what's causing them to saturate by watching time series and looking at spectra.
As usual, we noticed the frame builder wasn't connecting happily with the rest of the computers just as we were about to lock some stuff (we never notice it being bad when we're not trying to use the frame builder....)
All the big rectangles by each computer were white. I restarted daqd, and that brought most things back. c1lsc and c1sus needed their mx_streams restarted manually to get everything green again.
I've had about enough whine with my computers for tonight.
I'm starting to feel like a wine-o here. Yuta wanted to glance at the PRM oplev dataviewer, and lo and behold, the fb lost connection just as he decided to do that. We had checked the front end status screen not 1 minute beforehand, and everything was green. Lame.
Did we turn off minute trend writing in one of the recent FrameBuilder debug sessions? Seems we only have second trends in 2016. Maybe this explains why its so slow to get minute trends? Dataviewer has to rebuild it from second trend.
controls@nodus|frames > l
drwx------ 2 root root 16384 Jun 8 2009 lost+found/
drwxr-xr-x 2 controls controls 4096 Jul 14 2015 tmp/
-rw-r--r-- 1 controls controls 0 Jul 14 2015 test-file
drwxr-xr-x 5 controls controls 4096 Apr 7 2016 trend/
drwxr-xr-x 4 root root 4096 Apr 11 2016 archive/
drwxr-xr-x 789 controls controls 36864 Jan 13 19:34 full/
controls@nodus|frames > cd trend
controls@nodus|trend > l
drwxr-xr-x 258 controls controls 3342336 Jul 6 2015 minute_raw/
drwxr-xr-x 387 controls controls 36864 Nov 5 2015 minute/
drwxr-xr-x 969 controls controls 36864 Jan 13 19:49 second/
Yes, writing minute trends causes hourly FB crashes in the current state of things. The "raw" minute trending is turned on, but I think that these are unknown to nds.
Tomorrow's main goal is : let the both X and Y green light come out from the chambers.
Plan of the in-vac work for tomorrow :
- Removal of the access connector and the BS north door, starting from 9:00 AM. (requires 6 people)
- If necessary, align ITMs and ETMs to get the green light nicely flashing / locked.
- Take pictures of the BS and IOO table before installing / repositioning some optics.
- Repositioning of the green periscope in the BS chamber to let the Y green light go through it.
- Steer some green mirrors on the IOO table to let the Y green light come out from the chamber.
- Steer some green mirrors on the BS table to let the X green light come out from the chamber.
- Put some beam traps on the BS table
- Leveling of the BS table. (Do we need to level the IOO table ? it will change the spot positions on the MC mirrors somewhat)
- Take pictures again.
- Extra jobs : if we still have some more times, lock MC and check the beam clearance at the Faraday. Also check some possible beam clippings for the IR beam.
- Close the chamber with the light doors.
- Softball game at 6:30 PM.
Here is the Gantt chart we discussed in the 40m meeting today.
Based on the discussions we had, I applied a little bit of corrections on the chart but the main stream remains the same.
We have been waiting for this for 20 some years. Arrowhead water with cooler. AWESOME
Happy holidays, everyone!
I've put 5 EM172 microphones close together and measured there signal and coherence. They are plugged in to accelerometer channels.
Then I've suspended microphones around the MC - 2 at MC2, 2 at MC1,3 and 1 at PSL. The amplifier box is above STS readout box.
Microphone close to PSL gave a strong coherence with MC_F, as we already saw it using Blue Bird Microphone.
ACC_MC2_XY channels <=> MC2 microphones
ACC_MC1_XY channels <=> MC1,3 microphones
ACC_MC1_Z channel <=> PSL microphones
For Yuta's business, I intentionally misaligned the wideband EOM slightly to Yaw direction. Good luck.
It should show a big AM component at photo detectors.
I touched only the top right knob on the EOM mount and tweaked it by exactly 2 turns in counterclockwise direction.
I noticed a couple potential issues in some of the models while I was investigating the ADC/DAC situation:
c1ioo links to ADC1, but there are broken links to the bus selector that is supposed to be pulling out channels to go into the PSL block. They're pulling channels from ADC0, which it's not connected to, which means these connections are broken. I don't know if this means the current situation is broken, or if the model was changed but not recompiled, or what. But it needs to be fixed.
c1scy connects ADC_0_11, label "ALS_PZT", to an EpicsOutput called "ALS_LASER_TEMP", which means the exposed channel is called "C1:SCY-ALS_LASER_TEMP". This is almost certainly not what we want. I don't know why it was done this way, but it probably needs to be fixed. If we need and EPICS record for this channel it should come from the ALS library part, so it gets the correct name and is available from both ends.
Today I wanted to investigate the MC Length path situation for obscure reasons.
Jamie has started to revert the "ALTPOS" effect on the MC mirrors. So far, the screens and SLOW channels have been fixed, but the fast channels still say "ALTPOS" in the dataviewer instead of "MCL".
I also noticed that all of our old ADCU channels for diagnosing the PSL, MC, ISS, PMC ,etc. are completely AWOL. Let's blame Joe.
I think that there are probably some ADC channels available and that we'll just have to figure out what Joe intended for this. We certainly need it if we want to diagnose our PMC, ISS, FSS, MC, etc. Kiwamu tells us that the old PSL/IOO AA chassis is being used for some of the GCV signals, so its likely that we just have to do the appropriate channel name mapping in the DAQCONFIG tool.
Forging ahead with no data, I made up some filters in the MC2-MCL filter bank so that there could be a stable crossover between the laser path. I was able to turn it on and get some suppression of the FSS-FAST control signal, but there's no way to be sure without the fast channels. We gotta get Jamie to help us out once he finished the ETM BO mess.
I think these are all very helpful and interesting plots. We should see some better performance using either of the DC DARM signals.
BUT, what we really need (instead of just the DC sweeps) is the DC sweep with the uncertainty/noise displayed as a shaded area on the plot, as Nic did for us in the pre-CESAR modelling.
Otherwise, the DC sweeps mistakenly indicate that many channels are good, whereas they really have an RMS noise larger than 100 pm due to low power levels or normalization by a noisy signal.
The vent will start from 1 st of August !
++++ Task List for the vent preparation ++++
+ Preparation of beam dumps (Jamie / Steve)
+ Health check of shadow sensor and measurement of the cross-coupling (Steve)
+ Measurement of the arm Lengths and estimation of the required precision (Kiwamu)
+ Alignment of the Y green beam (Suresh)
+ Alignment of the incident beam axis (Jenne)
+ Measurement of the MC spot positions (Suresh)
+ Loss measurement of the arm cavities (Kiwamu / volunteers)
++++ Task List for the post-vent activity ++++
+ 3f RFPDs (Koji / Rana)
+ EOM resonant circuit (Kiwamu)
+ Sophistication of the LSC model (Yoichi)
+ DRMI commissioning (Keiko / Anamaria)
We set up the mixer based FD to check out its noise performance.
It is being acquired as C1:GCV-XARM_FINE_OUT_DAQ.
We have calibrated it by driving the frequency of the RF signal generator and putting the value into the GAIN field. We got 100 kHz / 5450 counts; the _OUT_DAQ channel is now being recorded in units of Hz. The cable length has been adjusted so that the full mixer output can swing 16 MHz peak-peak before turning over.
Also, we did a lot of cable cleanup around the IO rack. Kiwamu and Suresh's setups were somewhat dismantled. The whole area was too messy and too hacky to be allowed to survive. Our "temporary" setups have a way of becoming permanent holding places for barrels, adapters, duct tape, etc.
Today I finished setting up the server that will replace the c1vac1/2 machines. I put it on the martian network at the unassigned IP 192.168.113.72. I assigned it the hostname c1vac and added it to the DNS lookup tables on chiara.
I created a new targets directory on the network drive for the new machine: /cvs/cds/caltech/target/c1vac. After setting EPICS environment environment variables according to 13681 and copying over (and modifiying) the files from /cvs/cds/caltech/target/c1auxex as templates, I was able to start a modbusIOC server on the new machine. I was able to read and write (soft) channel values to the EPICS IOC from other machines on the martian network.
I scripted it as a systemd-managed process which automatically starts on boot and restarts after failure, just as it is set up on c1auxex.
Gautam and I are removing the prototype Acromag chassis from the 1x4 rack to make room for the new c1susuax hardware. I shut down and disabled the modbusPSL service running on c1auxex, which serves the PSL diagnostic channels hosted by this chassis. The service will need to be restarted and reenabled once the chassis has been reinstalled elsewhere.
The mode cleaner is locked and the air conditioning is full on. So the the air conditioning doesn't seem to be so important for the lock to hold.
About 30 minutes ago the mode cleaner fell out of lock and has since not been able to hold lock for more than a couple seconds.
I'm not sure what happened. I was in the middle of taking measurements of the MC error point spectrum, which included adjusting the FAST gain. I've put all the gains back to their nominal levels but no luck. I'm not sure what else could have gone wrong. Seismic noise looks relatively quiet.
As it turned out, the setting of +26dB for the FSS Fast gain was making the NPRO PZT / Pockels cell crossover too unstable. This was the cause of the large ~30 kHz peak that Jamie was seeing in his spectra (more to follow in the morning).
After recovering the locking, etc. by fiddling with the gains, we went about systematically setting all of the gains/offsets. Jamie's elog will show all of the various spectra with different FSS gains.
For offset setting, this was the procedure:
Let the MC lock and go through the UP script. When the MCL comes on with the integrator, the FAST voltage will shift from +5.5 V to something else. Use the following line: ezcaservo -r C1:PSL-FSS_FAST -g -1 -s 5.5 C1:SUS-MC2_MCL_OFFSET, to automatically tune the MCL offset.
I used our procedure from this entry to set the IMC board offset as well as the FSS board offset.
I found this afternoon that the MC was having trouble locking: the PC path was railing as soon as the boost was engaged. Could be that there's some misalignment on the PSL which has led to some RAM having to be canceled by this new offset. Let's see if its stable for awhile.
Having trouble again, starting around 1 hour ago. No one in the VEA. Adjusted the offset -seems to be OK again.
I felt in my bones that the MC was in trouble so I came by and noticed that it hadn't locked for a couple hours. The FSS SLOW was at -1.6V, but putting it back to zero didn't fix things. I adjusted the FSS error point offset to +1 and that took the FSS_FAST off of the +10 V rail. Relocked and seems OK.
We need to plan to make the M Evans mod to the FSS box to make the PC drive less angry.
Last 40 days of MC Alignment trends show that the recent MC WFS tuning / offseting worked out OK. MC REFL seems low and flat.
I started mode matching of the beam going to IMC. The work is still going on.
According to Rana's calculation (see here), I put the first lens (f=200mm) in between two steering mirrors after PMC.
The distance from PMC to the first lens was adjusted by using a metal ruler. So I believe the accuracy is something like 1mm.
I aligned the beam path going through the broadband EOM and the mode matching lenses.
I could find the optimum position for the second lens (f=-150mm) by sliding the position of the lens and measuring the mode after it.
But the optimum position looked a bit far from the EOM. It's off by about 3-4 inch from the designed position.
Somehow I feel that the beam before the second lens goes with a smaller divergence angle than that of designed.
So tomorrow I am going to restart the work from checking the mode before the second lens.
Maybe at first I should measure the mode without going through the EOM because it changes the waist position and makes the system not straightforward.
I have been working on the mode matching lenses which are sitting after the boradband EOM.
Last Friday I checked the mode profile after the first mode matching lens (f=-150mm). The measured mode was good.
According to the calculation done by ABCD software, the waist size is supposed to be 80.9 um after that lens.
The measured waists are 80.5 um for the vertical mode and 79.4 um for the horizontal mode.
The screenshot of the ABCD's result and the plot for the mode measurement are shown below.
I didn't carefully check the mode after the last convex lens (f=200mm), but it must be already good because the beam looks having a long rayleigh range.
Now the beam is reflected back from MC1 and goes to the AP table since I coarsely aligned the beam axis to the MC.
/**** fitting result ****/
w0_v = 80.4615 +/- 0.1695 [um]
w0_h = 79.4468 +/- 0.1889 [um]
z_v = -0.115234 +/- 0.0005206 [m]
z_h = -0.109722 +/- 0.0005753 [m]
We decided not to care about the mode after MMT1.
So far Koji, Alberto and I have measured the beam profile after MMT1,
but we are going to stop this measurement and go ahead to the next step i.e. putting MMT2
There are two reasons why we don't care about the profile after MMT1:
(1) it is difficult to fit the measured data
(2) The position of MMT1 is not critical for the mode matching to the IFO.
The details are below.
(1) difficulty in fitting the data
The precision of each measured point looked good enough, but the fitting result varies every measurement.
The below shows the data and their fitted curves.
In the label, "h" and "v" stand for "horizontal" and "vertical" respectively.
The solid curves represent the fitting results, varying by each measurement.
In order to increase the reliability of the fitting, we had to take some more data at further distance.
But we couldn't do it, because the beam radius already becomes 3 mm even at 2 m away from MMT1 and at this point it starts to be clipped on the aperture of the beam scan.
Thus it is difficult to increase the reliability of the fitting.
Once if we put MMT2 the beam should have a long Rayleigh range, it means we can measure the profile at further distance, and the fitting must be more reliable.
(2) positioning of MMTs
Actually the position of MMT1 is not so critical for the mode matching.
The most important point is the separation distance of MMT1 and MMT2.
As written in Jenne's document, if we slide the positions of MMT1 and MMT2 while keeping their appropriate separation distance, the mode match overlap still stays above 99%
This is because the beam coming from MC3 is almost collimated (ZR~8m), so the position of MMTs doesn't so matter.
To confirm it for the real case, I also computed the mode overlap while sliding the position of MMTs by using real data. The below is the computed result.
It is computed by using the measured profile after MC3 (see the past entry).
The overlap still stay above 99% when the distance from MC to MMT is between 1300 and 3000mm.
This result suggests to us putting MMT1 as we like.
I improved the mode matching of the incident beam to the doubling crystal on the PSL table.
As a result it apparently got better (i.e. brighter green beam), but it's not the best because now the beam is a little too tightly focused on the crystal.
I am going to work on it again someday after seeing the beat note signal.
- The measured waist sizes are
41.94 [um] for vertical mode
42.20 [um] for horizontal mode
while the optimum waist size is 50 um (see entry #3330).
The plot below shows the beam scan data which I took after improving the mode match.
The mode profile of the new input optics was measured.
Although the distance between each optic was not exactly the same as the design because of narrow space,
we measured the profile after the curved mirror (MMT1) that Jenne and Kevin put in the last week.
(interference from MMT1)
Below is a sketch of the current optical path inside of the chamber.
In the beginning of this measurement, the angle between the incident and the reflection on MMT1 (denoted as theta on the sketch) was relatively big (~40deg) although MMT1 was actually made for 0deg incident.
At that time we found a spatially large interference imposed on the Gaussian beam at the beam scan. This is not good for mode measurement
This bad interference can be caused by an extra reflection from the back surface of MMT1 because the interference completely vanished by removing MMT1 .
In order to reduce the interference we decreased the angle theta as small as possible. Actually we made it less than 10deg which was our best due to narrow space.
Now the interference got less and the spot looks better.
The picture below shows an example of the beam shape taken by using the beam scan.
Top panel represents the horizontal mode and bottom panel represents the vertical mode.
You can see some bumps caused by the interference on the horizontal mode, these bumps may lead to overestimation of the horizontal spot size .
The above plot shows the result of the mode measurement.
Here are the parameter obtained by fitting. The data is also attached as attachment:4
Just note that MMT1 has RoC of -5m (negative!). This means that it is a lens with f=-2.5 m,
I corrected the sketch of the new IOO.
The sketch in the last entry was also replaced by the new one.
I checked the measured data of the mode profile which was taken on the last Tuesday.
For the vertical profile,
the plot shows a good agreement between the expected radius which is computed from the past measurement, and that measured on the last Tuesday.
However for the horizontal profile,
it looks like being overestimated. This disagreement may come from the interference imposed on the Gaussian spot as we've been worried.
So I guess we should solve this issue before restarting this mode matching work.
- The next step we should do are;
checking the effect of MMT1 on the shape of the beam spot by using a spare of MMT1
The expected curve in the attached figure were computed by using the fitted parameter listed on the entry 2984 .
In the calculation the MMT1 is placed at 1911mm away from MC3 as we measured.
And the focal length of MMT1 is set to be f=-2500mm.
So we should solve this issue before restarting this mode matching work.
checking the effect of MMT1 on the shape of the beam spot by using spare MMT1
When / if you use the other MMT1 mirror, make sure to take note whether or not it says "SPARE" on it in pencil. I don't remember if it's the other MMT1, or if it's one of the MMT2's that says this. The mirror was baked, so it's okay to use in the vacuum, however it's the one which was dropped on the floor (just prior to baking), so any discrepancies measured using that optic may not be useful. I don't know how strong the CVI coatings are to scratches resulting in being dropped from a ~1m height. Bob and I didn't see any obvious big scratches that day, but that doesn't necessarily give it a clean bill of health.
The optic labeled "SPARE" should NOT be used as the final one in the IFO.
For the record, we wanted to check whether the fringes on the beam spot were caused by SM2 (see diagram above). We tried two different mirrors for SM2,
The first was one of the flat, 45 degree ones that were already on the BS table. The last, which is the one currently in place, was inside the plastic box with the clean optics that Jenne left us .
The fringes were present in both cases.