July 29 Thu [Steve, Alberto, Kiwamu, Koji]
We placed some optics in the BS chamber.
The chambers are ready to be pumped down on Friday once the heavy door is placed.
- Clean room work
- In the chamber
- After closing the chamber
[Koji, Steve, Kiwamu, Alberto]
- This afternoon we installed a few new optics on the BS table: GR_PBS, GRY_SM2, GRY_SM1.
- We pulled up the cables so that we had more freedom to move one of the cable towers farther South.
- Then we re-leveled the table. PRM OSEMs were adjusted to be nominal insertions.
- Koji released the earthquake stops on BS but the readout of the OSEMs was apparently frozen on the MEDM screens.
Initially we thought it was a software problem. a nuclear reboot didn't solve it. We spent the following three hours investigating the cause.
Eventually it turned out that the earthquake stops on BS weren't actually fully released.
We opened the tank and accessed to BS. Releasing the earthquake stops in full solved the issue. The OSEMs readout went back to normal.
More photos were taken. Will post Monday, because too hungry now.
Have eaten. Here's a PDF with all the pictures to-date, along with a few notes.
Also, the first thing we did on Saturday was to fix the yaw pointing of MMT1, so that the beam hit the center of MMT2. Then we had to touch PZT2 to compensate. We put the iris target on the BS, and adjusted PZT2 until the beam went nicely through there. The resulting beam looks good on the SRM, and teh beam is still hitting the AS camera.
I'm back to terrorize the PSL table again. The pictures I took yesterday were rubbish--today I'm using a clamp that Steve was nice enough to loan me. I'm starting now, at 10:09 am.
See Attachment #1 for the projected control signal ASDs. The main assumption in the above is that all other control loops can be low-passed sufficiently such that even with anti-dewhitening, we won't run into saturation issues.
DARM control loop:
De-whitening and Anti-De-whitening:
It remains to add the control signals for Oplev, local damping, and ASC to make sure we have sufficient headroom, but given that current projections are predicting using up only ~1000cts of the ~23000cts (RMS) available from the DAC, I think it is likely we won't run into saturations. Need to also figure out what the implication of the reduced actuation range will be on handling the locking transient.
I think "OLG" trace is not labeled right; it would be good to see the actual OLG in addition to whatever that trace actually is.
Based on the first plot, however, my conclusion is that:
I was a bit hasty in posting the earlier plots. In the earlier plot, the "OLG" trace was OLG * anti dewhitening as Rana pointed out.
Here are the updated ones, and a cartoon (Attachment #5) of the loop topology I assumed. I've excluded things like violin filters, AA/AI etc. The overall gain scaling I mentioned in the previous elog amounts to changing the optical sensing response in this cartoon. I now also show the DARM suppression (Attachment #4) for this OLG and the DARM linewidths for RSE. I don't think the conclusions change.
Note that for Signal Recycling, which is what Kevin tells us we need to do, there is a DARM pole at ~150 Hz. I assume we will cancel this in the digital controller and so can achieve a similar OLG shape. This would modify the control signal spectrum a little around 150Hz. But for a UGF on the loop of ~150 Hz, we should still be able to roll-off the control signal at high frequencies and so the RMS shouldn't be dramatically affected.
Steve is looking into acquiring 4.5kohm Vishay Wirewound resistors with 1% tolerance. Plan is to install two in parallel (so that we get 2kohm effective resistance) and then snip off one once we are convinced we won't have any actuation range issues. Do these look okay? They're ~$1.50ea on mouser assuming we get 100. Do we need the non-inductive winding?
Good question! I've never calculated what the resonance frequency would be if had an inductive resistor with our cable capacitance (~50 pF/m I guess).
I connected to the serial port using screen (through Terminal) and using Arduino's serial monitor and basically received the same strings that were received through python, so it's not a python issue. Checked the other TC 200 module and was also receiving nonsense, but it was all question marks instead of mostly K's and ['s.
This rules out a few possible reasons for the weird data. Next steps are to set up and configure the Raspberry Pi (which has been interfaced before) and see if the problem continues.
I acquired several spare OSEMs (in unknown condition) from Paco. They are stored alongside the shipment from UF.
[Jenne, Koji, Rana]
Thanks to turning off the AS55 analog whitening as well as the 1k:6k lead filter that Koji put into Darm's FM7, the DARM transition was more stable early in the evening.
The AS55 gain and offset did not change noticeably when we switched the AA on or off (switching happened while *not* using AS for any feedback). Earlier in the evening, we did also check what happened with PRMI and REFL33 AA on vs. off, and REFL33 did have a many tens of counts offset on both the I and Q input channels. I have turned the AA filters back on, but run LSCoffsets before trying to lock.
I'm not sure what was up, but somehow I couldn't lock the PRMI for about half an hour or so. Very frustrating. Eventually after futzing around, I was able to get it to lock with REFL33 in PRMI-only, and after that it worked again in PRFPMI with REFL165.
With FSS slow around 0.5, MC has been a bit fussy the last hour. Also frustrating.
Later on in the evening, I started taking out a bunch of the "sleep" commands from the up script, and many of the "press enter to continue" spots, but I think it might be moving too fast. That, or I'm just not catching where I have too much gain. Anyhow, near the middle/end of the CARM transition I am getting severe gain peaking at several hundred Hz. I think I need to use a lower final gain.
So, progress on DARM, but maybe a little more fine-tuning of CARM needed.
Here's a DARM loop measurement, taken after both CARM and DARM were RF-only:
I have modified the DARM model from elog 11133, to include the fact that these are digital filters.
I have also extracted the data from elog 11143, and it together with the model.
The modeled loop has an arbitrary gain factor, to make it have the same 234Hz UGF as the measured data.
The modeled loop includes:
There is a 1.5 degree phase discrepancy at 100Hz, and an 11 degree phase discrepancy at 900Hz, but other than that, the modeled and measured loops match pretty well.
For the measured frequencies, here are the residuals:
- Today the spots were moving more than the usual. The OPLEV screens showed that the spots are too much off from the center.
- Each vertex OPLEVs were checked and OPLEV wonderland was discovered: Other than the usual misalignment of the spots,
it was found that PRM/ITMX/ITMY beams were clipped somewhere in the paths, BS/PRM oplevs had many loose components
including the input lenses (they are still clamped by a single dog clamp THIS SHOULD BE FIXED ASAP).
- On the ITMY table there were so many stray optics. They were removed and put on the wagon next to the ITMY table.
THIS SHOULD BE CLEARED ON THE WEDNESDAY CLEANING SESSION.
- During this OPLEV session, LSCoffset nulling was run.
- After the OPLEV session, the locking became really instantaneous. We wonder which of the OPLEV cleaning, LSC offset nulling,
and the usual seismic activity decay in the evening was effective to make it better.
- Initially the lock was attempted with REFL33I/Q and some ~10sec lock streches were obtained. During this lock,
the optical gain of AS55Q was measured in relative to REFL33Q. In deed they were calibrated to be the same
gain at the input matrix.
- After the MICH signal source was switched to AS55Q, the lock streches became more regular and the minutes long.
We precisely tuned the phase of AS55 and REFL55 in terms of the differential excitation of ITMX/Y using lockin (FREQ 250, AMP 1000).
- We noticed that the AS port spot with AS55Q MICH was darker than the REFL33Q MICH. This suggests the existence of residual offset
in REFL33Q. In deed we observed +30cnt offset in REFL33Q when the PRMI is locked with AS55Q MICH.
- Phases and relative gains of the signals were as follows:
PRCL: REFL33I 1.00 =REFL55I +0.4
MICH: AS55Q 29deg x1.00 = REFL33Q -14deg x1.00 = REFL55Q 118deg 0.03?
- We tried to lock PRMI with AS55Q. The acquisition was not as easy as that with REFL33I. This might be from the saturation of the
REFL55I signal. This configuration should tested with different whitening gain. Handing off using the input matrix went well once the
lock was obtained by REFL33I.
- Handing off from AS55Q to REFL55Q was not successful.
- At the end of the session, Jenne told me that the POP PD still has a large diameter beam. (and a steering mirror with a peculiar reflection angle.)
==> THIS SHOULD BE FIXED ASAP because the normalization factor can be too much susceptible to the misalignment of the spot.
- The configuration of the filters:
PRCL FM3/4/5/6 G=+0.05 / NORM 0.04 POP110I
MICH FM4/5 G=-5.00 / NORM 0.01 POP110I (or none)
I locked each arm, and the Michelson last night, no problems after I increased the Yarm gain from 0.1 to 0.2 . I checked the green beam alignment just before going home, and both of the green beams are locking on ~03 or 04 modes, so aligning them is on the list for today.
I now think the excess noise in this circuit could be coming from the KEPCO switching power supply (in fact, the supplies are linear, and specd for a voltage ripple at the level of <0.002% of the output - this is pretty good I think, hard to find much better).
All component references are w.r.t. the schematic. For this test, I decided to stuff a fresh channel on the board, with new components, just to rule out some funky behavior of the channel I had already stuffed. I decoupled the HV amplifier stage and the Acromag DAC noise filtering stages by leaving R3 open. Then, I shorted the non-inverting input of the PA95 (i.e. TP3) to GND, with a jumper cable. Then I measured the noise at TP5, using the AC coupling pomona box (although in principle, there is no need for this as the DC voltage should be zero, but I opted to use it just in case). The characteristic bump in the spectra at ~100Hz-1kHz was still evident, see the bottom row of Attachment #1. The expected voltage noise in this configuration, according to my SPICE model, is ~10 nV/rtHz, see the analysis note.
As a second test, I decided to measure the voltage noise of the power supply - there isn't a convenient monitor point on the circuit to directly probe the +/- HV supply rails (I didn't want any exposed HV conductors on the PCB) - so I measured the voltage noise at the 3-pin connector supplying power to the 2U chassis (i.e. the circuit itself was disconnected for this measurement, I'm measuring the noise of the supply itself). The output is supposedly differential - so I used the SR785 input "Float" mode, and used the Pomona AC coupling box once again to block the large DC voltage and avoid damage to the SR785. The results are summarized in the top row of Attachment #1.
The shape of the spectra suggests to me that the power supply noise is polluting the output noise - Koji suggested measuring the coherence between the channels, I'll try and do this in a safe way but I'm hesitant to use hacky clips for the High Voltage. The PA95 datasheet says nothing about its PSRR, and seems like the Spice model doesn't include it either. It would seem that a PSRR of <60dB at 100 Hz would explain the excess noise seen in the output. Typically, for other Op-Amps, the PSRR falls off as 1/f. The CMRR (which is distinct from the PSRR) is spec'd at 98 dB at DC, and for other OpAmps, I've seen that the CMRR is typically higher than the PSRR. I'm trying to make a case here that it's not unreasonable if the PA95 has a PSRR <= 60dB @100 Hz.
So what are the possible coupling mechanisms and how can we mitigate it?
What do the analog electronics experts think? I may be completely off the rails and imagining things here.
Update 2130: I measured the coherence between the positive supply rail and the output, under the same conditions (i.e. HV stage isolated, input shorted to ground). See Attachment #2 - the coherence does mirror the "bump" seen in the output voltage noise - but the coherence is. only 0.1, even with 100 averages, suggesting the coupling is not directly linear - anyways, I think it's worth it to try adding some extra decoupling, I'm sourcing the HV 10uF capacitors now.
Yes. The datasheet has a recommendation circuit with 10uF caps. Companies are careful to show reproducible, reliably functional circuit examples on datasheets. So, if the caps are there you should try to replicate the design.
Additional bypass capacitors? I use 0.1 uF, 700V DC ceramic capacitors as bypass capacitors close to the leads of the PA95, as is recommended in the datasheet. Can adding a 10uF capacitor in parallel provide better filtering? I'm not sure if one with compatible footprint and voltage rating is readily available, I'll look around.
true. also try to choose a cap with a goow high frequency response. In the Electronics Noise book by Ott there's some graph about this. I bet you good do a Bing search and also find something more modern. Basically we want to make sure that the self resonance is not happening at low frequencies. Might be tought to find one with a good HF response, a high voltage rating, and > 1uF.
I'm still having issues with the STACIS oscillating uncontrollably with the slightest extra vibration, but with some more added weight both x and z direction are stable if you don't disturb the setup.
I took more transfer functions of the STACIS. In the last data I took Jenne pointed out that the geophone signals were not correlated well with the driving signal, so I increased the amplitude of the driving signal and am looking in x and y too instead of just z.
Details of the driving signal: 25 mV, swept sine from 0.1 to 100 Hz from the SR785.
NOTE: The data below was all transferred from the SR785 using netGPIB, which works fine, if anyone was interested in using it.
Open loop in the y direction, taken with the y geophone (magnitude on top, phase on bottom):
Open loop in the x direction, taken with the x geophone (with some extra weight to try to make the closed loop more stable):
Open loop in the x direction, taken with accelerometer instead of geophone:
The vac controls system is going down for migration from Python 2.7 to 3.4. Will advise when it is back up.
I've converted all the vac control system code to run on Python 3.4, the latest version available through the Debian package manager. Note that these codes now REQUIRE Python 3.x. We decided there was no need to preserve Python 2.x compatibility. I'm leaving the vac system returned to its nominal state ("vacuum normal + RGA").
Five Agilent pressure gauges were delivered to the 40m. It is stored with the controller and cables in the office area. This completes the inventory for the gauge replacement - we have all the ordered parts in hand (though. not necessarily all the adaptor flanges etc). I'll see if I can find some cabinet space in the VEA to store these, the clutter is getting out of hand again...
in addition, the spare gate valve from LHO was also delivered today to the 40m. It is stored at EX with the other spare valves.
It is stored along with the cables that arrived a few weeks ago, awaiting the gauges which are now expected next week sometime.
I'm trying to get more of the simplant models running so that we (me and Sasha Surf) can get a full real-time cavity simplant running. As I reported last week, c1spx is running again on c1iscex.
The two new simplant models are c1sup, which holds the simplant for ITMX, and c1lsp, which holds the IFO simplant, specifically the one we're working on for XARM.
Here's the relevant info:
model host dcuid cpu
c1spx c1iscex 61 4
c1sup c1sus 62 6
c1lsp c1lsc 60 6
c1spx and c1sup will be running the sus_single_plant parts for ETMX and ITMX simplant. All the simplant suspension channels will be names "SUP" (as opposed to "SUS" for control).
c1lsp is now running, but c1sup won't run for unknown reasons. The c1sup model is not very complicated, and in fact is more-or-less identical to c1spx. It compiles and installs and even loads, but it completely unresponsive after loading. Unfortunately I've had enough CDS bullshit for today, so I'll try to figure out what's going on tomorrow.
Sanjit has been working today on trying to get the OAF coefficients to save properly. Alex got us most of the way, but right now it's looking like the filter that is being saved is totally constant (all the values are the same). We're poking around trying to figure out why this is.
Also, we're starting again (as we should have been for the last week or so since Alex came in to help us) to check in the TOP_XFCODE whenever we make changes to it, and when we recompile the front end code.
We are manually restarting assepics, but the terminal logs us out after sometime and ass may crash. I set autologout=0 in the terminal for the time being. Once the testing process is over, assepics will start automatically when the computer is turned on, so we wont have to worry about this.
(if ass crashes tonight, it is not unexpected!)
I made some changes in the code (all commented in the installed and SVN version) to print the filter coefficients. I got crazy output. Sometimes memory bugs lead to such crazy behavior. So far I could not find any bugs, but will have to spend more time on it.
I made some changes in the code (all commented in the installed and SVN version) to print the filter coefficients. I got crazy output. Sometimes memory bugs lead to such crazy behavior. So far I could not find any bugs, but will have to spend more time on it
Something strange was going on in the OAF code, printf would print a double precision number in %f format but not in %lf or %e format!
Since we know this problem now, we can move forward, but it will be important to know why printf was restricted and if there are other such constraints which we should remember while making changes in the codes.
1) Filled in the C1SUS_BS_OLMATRIX properly so as to make the BS oplev work for Steve.
2) Turned on the ITMX damping. Apparently it had tripped this morning, possibly due to work in the lab area.
3) The ETMX FE controller (c1scx) had ADC timed out and died sometime around 8:30 am. The c1x01 (the IOP on the ETMX computer) was also indicating a FB status error (mismatch in DAQ channels).
The reported error in dmesg on c1iscex was:
[1628690.250002] c1spx: ADC TIMEOUT 0 3541 21 3605
[1628690.250002] c1scx: ADC TIMEOUT 0 3541 21 3605
Just to be safe, I rebuilt the c1x01 and c1scx models, ran ./activateDAQ.py, and used the scripts killc1spx, killc1scx, and killc1x01.
I finally restarted the process with startc1x01, startc1scx, and startc1spx. Everything is currently alive and indicating all green.
I am putting a little bit of brain power into reviving the ASS, and I want to write down what the motivation is, and what the short and long-term plans are.
The IFO IR is not optimally aligned right now. While we were at atmosphere, we should have taken the time to align the green beams to the arms until the greens were both resonating TEM00. We were lazy, and excited to pump down, so we decided that locking on higher order modes was good enough to ensure the beams came out of vacuum. Once we were pumped down, ITMY and ETMY were aligned to the green beam axis. Then, the IR was aligned to this new Yarm cavity axis. This would have been okay, and pretty close, if we had aligned the green beam all the way (used only the outside steering mirrors to resonate TEM00, after the cavity mirrors were aligned for flashing IR). After the IR was aligned to the Ygreen axis, the rest of the IFO was aligned to this slightly-incorrect input pointing. We want to measure the IR spot positions on ITMY and ETMY so that we can tweak the input pointing until we hit the center of both ITMY and ETMY. Then we will align Ygreen's input pointing to this proper IR cavity axis. The rest of the IFO alignment will also have to be redone. This calls for a functioning A2L system, so the measurement part of the ASS.
The immediate motivation for measuring the spot positions is that the current Xarm IR axis is not at all very close to the Xgreen axis. The other day while we were fixing up the Xend table (note in elog 8162), we found that the TRX beam to the TRX PD and the trans camera was clipped on the 2" harmonic separator (which is the first optic that the transmitted IR beam sees on the end tables). It was clipping on the left side of the optic, if you are looking at the face of the optic. This is the more east-erly side of the optic. We moved that optic to the side so that we were not clipping. Then, today when Manasa was trying to align the Xgreen beam, she found that it was clipping on the right side of the harmonic separator, the more west-erly side. I remember seeing that the green beam was roughly centered on the harmonic separator when we were at atmosphere, so this clipping is certainly due to Yuta, Evan and my moving of the harmonic separator. Since the end green steering optics are not very orthogonal in angle/translation, it is very difficult to translate the beam by a significant amount. If we keep the current IR alignment, which surely isn't good anyway (you can see on the ETMXF camera that the beam isn't centered), we would probably have to move the Xgreen steering optics, which would be a total pain. It seems that the better plan is to leave them where they are, and get the IR pointing in the correct direction, and move the harmonic separator back to where it was originally.
Short term (< few days):
Write the arm section of the existing MeasureSpotPositions.py script (in ....../scripts/ASS). Write a wrapper script that, like ...../scripts/ASS/MC/mcassMCdecenter, calls sets up the lockins, runs MeasureSpotPositions.py, and calculates the calibrated spot positions. Use this information to hand tweak the input pointing, then realign the cavities to the new IR, and the greens to the new cavity axes.
All of the infrastructure for this is already in place in the c1ass model. The only drawback to the current situation is the LSC output matrix only has one row for ASS, and so only one cavity can be measured at a time. To make things faster, we could consider increasing the size of the LSC output matrix so that the 2 arms could be measured simultaneously. This change is low priority for now.
Make the full ASS system work.
A major change from the current situation is that the current ASS cannot actuate on the input pointing (TT1 and TT2 for Yarm, BS for Xarm). We want a low bandwidth servo to force the input beam to follow the cavity axis. Implementing this will require some changes to the ASS model.
Remeasure sensing matrix, test system.
I have modified the MeasureSpotPositions.py script to accept the arms as valid cavities (it used to give an error "Sorry, this only works for MC right now").
There is still no wrapper script to turn on lockins and turn them off after the measurement, so I have not tested the arm A2L yet. But I should be able to tomorrow, or whenever the IFO is next available.
* Write the wrapper script (analog of mcassMCdecenter).
* Fix arm assOff, assDown, assOn, assUp scripts to match the current channel names (which were changed long ago to be human-readable, versus mysterious numbers).
Andri and I mounted the Raicol Crystal #724 in one of the new Covesion Ovens. The procedure was the same as before - see elog entry here.
There was one issue - the glass plate that goes on top of the crystal is coated on one side with ITO (Indium-Tin Oxide) and it's not 100% certain that this was mounted in the correct orientation. It is virtually impossible to tell which side of the glass is coated.
The base plate of the oven was tapped for an M3 hole. We retapped it for an 8-32 and bolted it to a post and that one of the New Focus 4-axis translation stage. The assembly is currently bolted to the PSL table, awaiting use.
I mounted the new projector to the pipe where the old projector was attached. The mounting hardware wasn't designed for attaching to a pipe, but with Steve's help I mounted the projector. The projector is angled away from the area of the wall designated as the screen, and I am going to meet with Steve Monday to fix this.
Because of the network interference we've had from the CLIO system for the past 3-4 days, I asked the guys to remove
the test stand from the 40m lab area. It is now in the 40m control room. Since it needed an ethernet connection to get out
for some reason we've let them hook into GC. Also, instead of using a real timing signal slaved to the GPS, Jay suggested
just skipping it and having the Timing Slave talk to itself by looping back the fiber with the timing signal. Osamu will enter
more details, but this is just to give a status update.
I moved the RCG to the advLigoRTS-2.5 tag:
controls@c1iscey ~ 0$ ls -al /opt/rtcds/rtscore/release
lrwxrwxrwx 1 controls 1001 19 Jul 30 12:02 /opt/rtcds/rtscore/release -> tags/advLigoRTS-2.5
controls@c1iscey ~ 0$
There are only very minor differences between what we were running on the the 2.5 branch. I have NOT rebuilt all the models yet.
I was hoping that there was something in the tagged release that might fix this hard-crash-on-filter-load issue that we're seeing in the c1tst model. It didn't. Still have no idea what's going on there.
I moved the RCG to the advLigoRTS-2.5 tag
After that RFM -> OAF communication through PCIE became bad again. Inside CommData2.c cache flushing is not allowed
// If PCIE comms show errors, may want to add this cache flushing
if(ipcInfo[ii].netType == IPCIE)
clflush_cache_range (ipcInfo[ii].pIpcData->dBlock[sendBlock][ipcIndex].data, 16);
As a result, a significant part of MC_F and other signals is lost during RFM -> OAF transmission (270 - 330 out of 2048 per second)
Last time when I replaced 0 for 1, it suspended SUS machine because of the code bug. Alex modified a couple of files in the old version and it started to work. Do you know if this bug is fixed in the new version?
We moved chiara to 1X7 above nodus and powered with same UPS from a battery backed port. The UPS is at 40% load capacity. The nameserver and nfs came back online automatically on boot up.
We looked at the DRMI noise spectrum and chose new excitation frequencies such that the lines are lower in frequency than before (~300 Hz instead of 800 Hz) and also not in some noisy region.
New filters is saved and loaded for all LSC DOFs.
POP110 and POP22 demod angles were adjusted for DRMI lock.
Last week, I never achieved a fully 1F lock, REFL165 was used for SRCL. Tonight, we created input matrix settings for pure 1F locking, and did some signal mixing to reduce the PRCL to SRCL coupling. The PRCL to MICH coupling was already low, since AS55 is fairly insensitive to PRCL.
Similarly, for the 3F signals, some signal mixing of REFL33I and REFL165Q was used to reduce the PRCL to MICH coupling. The PRCL to SRCL coupling in REFL165 isn't too bad, so no compensation was done. Interestingly, in this setting, the 3F MICH and SRCL signals agree with the 1F signals on their zero crossing, so no offsets are needed. REFL33 I does need an offset, however, to match the REFL11I PRCL zero crossing.
The DRMI acquires faster with SRCL set to 165I. Once acquired, the 1F/3F can be made smoothly, and both settings are very stable. The sensing matrix in each setting is consistent with each other. (The PRCL and SRCL lines in AS55 change, but really I shouldn't even plot them, since they're not very coherent).
For some reason, these show a sign flip relative to last week's measurements. The relative angles are consistent, though.
Next up is finding the right coefficient for the SRM in the MICH output matrix, when actuating on the BS.
Last night, and again just now, I used the ./MC2_spot_[direction] scripts to center the MC2 spot on the trans QPD. The MCWFS handled overall alignment to correct for the fact that the ratios in the script aren't perfect. When I was finished, I ran the MC WFS relief script from the WFS screen. Last night, and again today, things had drifted until the yaw spot was more than 0.5 counts off.
As previously noted, there are multiple beams coming back from the ETM surface onto the PDH PD on the end table. They are spread out in a vertical pattern. All the spots swing together (as the ETM moves?).
I moved the PDH Green PD on the end table so that it was further away from the Faraday and I added an iris in between the Faraday and the PD. Now only the principle reflection from the ETM is incident on the PD. See attached photos. In order to sneak past the neighbouring optics, I had to steer the beam down a bit, so the PD is now lower than it previously was.
Just FYI: the angle between the returning beams is about 5 or 6 mrad at the PD. Before the beams get to the PD they go through a telescope that de-magnifies the beam by about 5 or 6 times. This implies that the angle between adjacent returning beams from the ETM is around 1 mrad at the ETM.
This does make the position of the spot on the PD more susceptible to the alignment of the ETM - we should use a short focal length lens and image the ETM plane onto the PD.
First image - overview of table
Second image - the three returning beams immediately before the IRIS
Third image - a close up of the IRIS and PDH PD.
Need a working IO chassis connected to c1ioo in order to bring the MC_L into the digital realm, and then via RFM transmit to the c1sus machine.
Move the c1iscey IO chassis to c1ioo while the c1ioo chassis is at downs.
The c1iscey chassis however doesn't seem to be talking to the c1ioo computer. I tried changing the host interface card on the c1ioo chassis. I took out One Stop Systems HIB2-x4-H interface card with serial number 26638 from the c1ioo computer and put in the One Stop Systems HIB2-x4-H with serial number 35242 in from c1iscey into c1ioo. Still didn't work.
All the lights are red on the interface card on the actual chassis and its cooling fan isn't spinning.
Using dmesg on c1ioo shows that it does not see any of the ADC/DAC/BO cards.
I'm going to wait until tomorrow morning when Rolf gets a chance to look at the c1ioo chassis over at Downs to determine the next step. If we fix the c1ioo chassis, I'm move the c1iscey chassis and its host interface board back to the end.
[Tega, Anchal, Paco]
After talking to Anchal, it was made clear that chiara is not the place to host the modbus service for the temperature sensors. The obvious machine is c1pem, but the startup cmd script loads c object files and it is not clear how easy it would integrate the modbus functionality since we can only login via telnet, so we decided to instead host the service on c1susaux. We also modified the /etc/motd file on c1susaucx which displays the welcome message during login to inform the user that this machine hosts the modbus service for the temperature sensor. Anchal plans to also document this information on the temperature sensor wiki at some point in the future when the page is updated to include what has been learnt so far.
We might also consider updating the database file to a more modern way of reading the temperature sensor data using FLOAT32_LE which is available on EPICs version 3.14 and above, instead of the current method which works but leaves the reader bemused by the bitwise operations that convert the two 16 bits words (A and B) to IEEE-754 32-bit float, via
field(INPC, "0x8000") # Hi word, sign bit
field(INPD, "0x7F80") # Hi word, exponent mask
field(INPE, "0x00FF") # Hi word, mantissa mask (incl hidden bit)
field(INPF, "150") # Exponent offset plus 23-bit mantissa shift
field(INPG, "0x0080") # Mantissa hidden bit
field(INPJ, "65536") # Hi/Lo mantissa ratio
as opposed to the more modern form
When I put away the lenses we had used for measuring the RF transfer functions of the QPD heads, I saw that I'd removed them from the cabinet containing green endtable optics, but hadn't noticed the sign forbidding their removal. I'll talk with Koji/Gautam about what happened and what should be done.
We moved our one STS1 from the x-arm end to the vortex. We record the data as STS1 in c1pem @ 256Hz. x is still north-south.
JD: This is actually an STS-2. We just call it C1:PEM-SEIS_STS1.... to differentiate the 3 STSs that we have from one another (assuming we plug in the other two).
[Paco, Ian, Tega]
We moved the white rack (formerly unused along the YARM) to a position between 1X3, and 1X4. For this task we temporarily removed the hepas near the enclosures, but have since restored them.
I looked at the CAD layout and it seems like we will clearly be clipping POY if we move SRM by 7.5cm. Since POY is not visible at low power, we cannot be sure about the clipping.
We should have a plan B before we move everything. I suggest we move a combination of SRM and SR2 to get the desired SRC length.
Moving SR2 will require extra effort to walk the beam unclipped through all the 6 output steering mirrors that follow; but there will be little room for error if we use irides to propagate the beam through the first 4 mirrors that are in the BS and ITMY chamber.
We turned off the power of the seismometers and moved the Guralp1 close to the STS. Both are now situated below the center of the mode cleaner vacuum tube.
We oriented the X axis of the STS & Guralp1 along the X axis of the interferometer. Then we turned on the power again, but the STS channels don't give any signal. We think this is, because we didn't push the auto zero button.
After pressing the auto-zero button (a lot of times) of the STS breakout box & aligning the bubble in the STS, we could finally get data from STS (Bacardi). So, now STS2 (Bacardi - Serial NR. 100151) is working!
The teststand has some non-trivial issue with Myrinet card (either software or hardware) which even teh experts are saying they don't remember how to fix it. CDS with mx was iin use more than a decade ago, so it is hard to find support for issues with it now and will be the same in future. We need to wrap up this test procedure one way or another now, so I have following two options moving forward:
So these are the two options we have. We should discuss which one to take in the mattermost chat or in upcoming meeting.