JeffK, JimW
I spent the afternoon trying to get feedforward working at ETMX, but I've had little luck so far. Currently, we are using a high blend on the St1, per Sebastiens posts last week. This costs us at low frequency, so we wanted to see if we could gain some of that back by getting extra performance out of HEPI. We would like to try feed forward, versus ground to st1 sensor correction, because this lets us partially get around the Z-RZ T240 coupling the seismic has been dealing with for a while, by reducing the amount we are driving on St1.
When I looked at EX initially, the HEPI platform had none of the Hua sensor correction/feedforward filters installed, so I copied the IIR from the EX ISI foton, and the FIR from the EY HEPI .fir file. When I tried turning on the HEPI STS Z feedforward loop, with a gain of .1 the ISI vertical drives started ringing up. After a few calls to Fabrice, I realized that, per JeffK's alog 13560, the EX HEPI had never had it's STS cal filter adjusted for the T240 we are temporarily using. I fixed that, and Jeff helped check that the ISI, HEPI and PEM sensors were all seeing the same ground. We then looked at the coherence between the St1 T240s and the ground. Currently the St1 sensor correction is working at EX, which affects that measurement. The attached 1st picture shows the coherence between the STS Z and the St1 Z, the black dashed line is with St1 senscor running, the green is without. The high green coherence is encouraging, it means we can do a lot of good with FF if we can get it running.
We then tried turning on the HEPI FF with a gain of .1 again, with the St1 senscor turned off. Pretty much immediately we saw a bunch of higher frequency stuff in the BLRMS and in a rolling DTT plot, my second attachment. After a bit, while we were distracted by HAM2, EX tripped in spectacular fashion (last two pics, first is zoomed on when I think we pushed the button, second is of the trip), so we've given up for the moment. EY might be easier, with it's more nominal configuration, but the filters installed in foton down there are not the Hua standard filters, so I'm not sure what has been done there. We also have a filter designed by RyanD that I can try, but that will require more foton copy/paste.
Dumped unpumped gate annulus volumes of GVs to be opened into pump carts -> Opened GV5, GV7 and GV18 -> Valved-in IP12 -> Valved-out X-end turbo -> Isolated and removed pump cart from BSC5 -> Opened GV20
Reset HEPI L4C WD counters for HAM2, HAM3, HAM4, HAM5, ITMX and ITMY.
J. Kissel, J. Warner, K. Izumi. Jim and I were working on ETMX; wiamu rolled over asking us what's up with HAM2 ISI. It had single-saturation tripped on actuators. We've got no idea. Our best guess is Kyle jumping around opening up the ARMs, but it's a terrible guess and probably not right. Sensor correction on HAM2 has been turned off since this morning. #fortherecord
HAM 2 tripped again later.
Following Joe's work at LLO on the ASCIMC model (see LLO alog 14538), I recompiled and restarted the h1ascimc model with the latest master library block. This was under WP#4864.
Here are the major changes that one might pay attention:
J. Kissel, J. Bartlett, J. Batch Bartlett reported that the damping loops were non-functional on his newest QUAD, using the now ancient infrastructure on bscteststand2, the front end which runs the x1susquad model. After a cursory check of COILOUT gains, EUL2OSEM and OSEM2EUL matrices, reminding ourselves that that test stand still uses old versions of the AA and AI chassis which invert the sign of the signals, confirming that these are compensated for in the OSEMINF and COILOUTF banks, and confirming that calibration filters are not needed, I found they were still non-functional. So, I tried the classic "I don't know what's happening" debug move and inverted the sign on the DAMP filter gains. With the sign flip, the damping loops are now stable. In order to capture these EPICs records so we don't have to go through this process again, Jeff suggested I show him how to take a safe.snap. I said "sure!" hoping that I can just use /opt/rtcds/userapps/release/cds/common/scripts/makeSafeBackup That didn't work (for reasons you'll find out later), so I just went for the core bit of code run in every burt capture, burtrb -f /opt/rtcds/${site}/${ifo}/target/${ifo}sus${optic}/${ifo}sus${optic}epics/burt/autoBurt.req > ${snapFileName} however, I thought for a second, "wait ... this is ancient RCG we're dealing with ... where is it looking to find the safe.snap?" Turns out, this test stand's RCG version is so old, the start script was still looking at files in the /tmp/ directory, which we know gets blown away upon computer reboot. Bad news. So, I dug into the /opt/rtcds/tst/x1/scripts/startx1susquad start up script, found the line that calls burtwb to burt restore the "safe.snap" file, and replaced the line fname='ls -t /tmp/x1susquad_burt_*.snap 2>/dev/null | head -1' with fname='ls -t /opt/rtcds/${site}/${ifo}/target/${ifo}susquad/${ifo}susquadepics/burt/safe.snap 2>/dev/null | head -1' which is where the current RCG startup script look. Indeed, most, if not all of these files in the target directory are soft-links to their respective location in the version controlled userapps repo: /opt/rtcds/userapps/release/sus/${ifo}/burtfiles/${ifo}sus${optic}_safe.snap I confirmed that this soft link does exist on the front end, so now the /opt/rtcds/tst/x1/scripts/startx1susquad uses the /opt/rtcds/${site}/${ifo}/target/${ifo}susquad/${ifo}susquadepics/burt/safe.snap to burt restore upon startup, which is a soft link to /opt/rtcds/userapps/release/sus/x1/burtfiles/x1susquad_safe.snap NOTE: If this model ever gets recompiled with the same RCG version, this startup script will be over-written with the old badness. As such, I've copied both the old and new versions of the startup script to /opt/rtcds/tst/x1/scripts/startx1susquad_looksattmpforsafe #bad old RCG auto-genetared version /opt/rtcds/tst/x1/scripts/startx1susquad_looksatuserappsforsafe #good new version Hopefully the filenames themselves are self-explanatory. Finally, I had to get back to my original problem, and make sure that the userapps copy of the safe.snap file was up-to-date. Turns out /opt/rtcds/userapps/release/cds/common/scripts/makeSafeBackup was failing because the environment variable ${USERAPP_DIR} was not defined on the suswork1 work station. #facepalm So I created the environment variable on both the work station (suswork1) and the front end (bscteststand2), export USERAPPS_DIR=/opt/rtcds/userapps/release and checked that it worked, controls@bscteststand2 /opt/rtcds/tst/x1/scripts $ echo ${USERAPPS_DIR} /opt/rtcds/userapps/release controls@suswork1:/opt/rtcds/tst/x1$ echo ${USERAPPS_DIR} /opt/rtcds/userapps/release Good great. Now save the dang backup. controls@suswork1:$ /opt/rtcds/userapps/release/cds/common/scripts/makeSafeBackup sus x1susquad controls@suswork1:$ cd controls@suswork1:/opt/rtcds/userapps/release/sus/x1/burtfiles controls@suswork1:$ svn commit -m "Saved with functional damping loop settings for latest testing." x1susquad_safe.snap controls@suswork1:$
QUAD 06 (Q6) Phase 1B transfer function plots are attached. We had a hard time obtaining good coherence in the Transverse TF, so it is a bit hashy. Will try again.
Most notably is that, like Q8, the second pitch mode frequency is unexpectedly pushed upward on the main chain. Recall, we never found the mechanism to fix it on Q8. Interestingly, both the Q8 and Q6 assemblies are of the same batch of wires and are fresh builds, but by 2 different assembly teams, and on 2 different solid stack/test stand units. Q8 is an ETM type of QUAD while Q6 is an ITM QUAD, but both main chains have the same pendulum parameters - both are detailed in the 'wireloop' model.
The Q6 data is plotted as QUADTST.
We've checked that all wire diameters are as per the specs and that the wire segment clamps are seated properly on the masses. We've also checked that the wire segments have been assembled with the proper assymetry as per specs (looking for something obvious).
Attached are pix of this unit, in case someone wants to look at them. To me, they look just like the last few QUADs we've built, including Q8.
Maybe this is a long shot, but we've exhausted all the simple causes...could the top wire be the wrong material? If the modulus of elasticity was higher, within a factor of 2 from where it is supposed to be, that would explain this strange pitch mode.
One way to test this is to measure the violin modes of the topmost wire in situ and see if it is right. Or maybe more simply, cut some wire from this wire stock, hang some wieght off of it, and measure its violin mode.
The correct 1.1 mm diameter wire should have a violin mode of
frequency in Hz = sqrt(tension/0.0067)/(2*L)
where 0.0067 is the mass per unit length.
For example tungsten has a modulus about 2 times higher than what we are supposed to have. If for whatever reason we ended up with a tungsten wire, it would have an in-situ violin mode in the low 200s of Hz, rather than the 332 Hz spec (much denser than the usual piano wire).
Or even more simply, you could weigh some length of wire. The piano wire should be something close to 7 g/m. If you get different value from that, then the wire is the wrong material.
To confirm Brett's latest suggest regarding the wrong wire: We have 2 rolls of 1.1mm diameter top wire here at LHO which could have possibly been used for QUAD builds. Both are labeled as the correct stuff. We weighed a 1m segment from each spool. One measures 7.1g, the other measures 7.3g.
To be continued...
Another sanity check:
The Top Mass blade sets used for these 3 pitch-problematic QUADs are as follows:
Q6 - SET 10
Q8 - SET 8 - although I can't find the actual records
Q9 - SET 2
Q7 - SET 7 - still to be tested, unknown pitch frequency TFs
The SETs go from SET 1 being the most STIFF to SET 16 being the most SOFT. So, the sets we are using for the 3IFO QUADs are somewhat scattered or in the middle of the pack. They are not all clustered at the soft end, nor all at the stiff end...
And here's the spectra of this Q6. Note, the lowest stage (L2) does not have flags during the all-metal Phase 1 assembly, so the spectra plots of L2 are junk.
And now attached are a damped TF from each R0 and M0. As we all have noted in SUS - damped TFs on Phase 1 test stands are not useful since the damping is a function of the code on the out-dated test stands and the loops are not tuned very well. Long story short, there is a little bit of damping evident, given whatever filters and gains are loaded, and we can see healthy excitations run through the suspension so all seems well with damping capabilities of Q6.
Weekly trend plots. Still need to work on the (non-auto) scales for the various plots.
The power noise measurement looks okay. Noisier than the reference measurement between 10 Hz and about 3 kHz. The diffracted power whilst averaging around 3% is wandering around a little - normally it's relatively flat. Whilst the frequency noise scan was being done, the reference cavity transmission was around 2.05 V, common gain 27 dB, fast gain 15 dB. It had been locked for ~10 hours. The frequency noise spectrum again has these "step" like features at low frequencies. This is about the 3rd or 4th week that this feature has been present. I suspect it will take more than the customary 4 hour Tuesday morning maintenance period to address this issue. It looks like we're not getting much bandwidth as the control and error signals intersect below 100 Hz. The beam pointing looks nominal. The mode scan looks nominal, higher order mode count 56, higher order mode power 4.6%. The relative power noise is noticeably worse than the previous measurement. A check of the diffracted power after the scan was done showed that the diffracted power was oscillating between 1% and 10%. Not obvious why. Environmentally there is a lot of seismic noise in the 1 - 3 Hz band. A screen shot of the ISS MEDM screen is attached.
It looks like every now and then a glitch occurs in the (as monitored) output of both the in and out of loop photodiodes, which causes the diffracted power to oscillate. I would have to check the schematics but it could be that a voltage regulator on the photodiode board is overheating and therefore oscillating. The room temperature reported is 22 degC.
no restart reported
J. Kissel I was warned that -- though all the GND STS channels are mapped from the instrument to the frames correctly now (see LHO aLOG 14072) -- what actually gets fed into the sensor correction filter banks is a total mess in the corner station. I've scoured the front-end simulink models, toggled some switches at the racks in the EE bay, and stomped on the ground near the STSs themselves trying to map it out, and all I can say is WOW do I agree. I'll work with the SEI and CDS groups to clean up. Here're the facts, as they stand now, in order of my discovery: (1) In reality, we want the following seismometer-location-to-channel map for all 17 digital instances of the signals in the corner (6 HAM HPIs, 5 HAM ISIs, 3 BSC HPIs, 3 BSC HPIs): Just +X of HAM2 => STS A In the Beer Garden => STS B Just +Y of HAM5 => STS C as determined by D1002704, revised due to Integration Issue 45, and DCN E1400111. (2) I've confirmed that the above mapping is correct for ITMY (the "master" front-end model responsible for storing these STSs and "GND" channels in the frames) by performing my finest hill-billy hoe-down near the respective STS, and watching the ISI-GND channels on a CDS laptop. (3) Because of the STS-2 analog distribution chassis, and that the SEI BSC wiring diagram (D0901301), and SEI HAM wiring diagrams (D1101584, D1101576, and D1000298) were written before the ABC convention was established and not addressed in E1400111, there're 17-choose-3 = 680 possible combinations, and I'm pretty sure we used all of them. Front end models: (4) ALL HAM-ISIs use the library part, ${userapps}/release/isi/common/models/isihammaster.mdl. There is another library, isiham236master.mdl, that looks deceiving in the same directory, but it's unused according to the tar balls of source code for what's actually running on the IFO. This should be removed from the repo. (5a) The HAM-ISIs are reasonably consistent, in that, ADC_0 or ADC_2 Channels 24-26 => STS A XYZ ADC_0 or ADC_2 Channels 28-30 => STS B XYZ ADC_1 or ADC_3 Channels 24-26 => STS C XYZ where it's ADC_0/1 on the "first" HAM-ISI in the I/O chassis, and ADC_2/3 on the "second" HAM-ISI (HAM2, HAM4, and HAM6 are the "firsts," HAM3 and HAM5 are the "seconds."). (5b) EXCEPT HAM2, who has ADC_0 channels 24-26 mapped into BOTH STS A and STS B. (6) Because of an RCG "feature" even though different ADC *card* numbers are used between the seconds and firsts, the block name is always ADC 0 or ADC 1. (7) The HAM-HPIs all use the same library part, ${userapps}/release/hpi/common/models. (8a) HPIs HAM2-5 have GND STSs hooked up, also, reasonably consistent in that they all use ADC_0 or ADC_2 Channels 24-26 => STS A XYZ all piped into STS A, with STS B and STSC terminated. Again, the "firsts" use ADC0, and the "seconds" use ADC 2. (8b) EXCEPT HAMs 1 & 6 have all STS inputs terminated. (9) The BSC ISIs and the BSC-HEPIs are consistent, but consistently bonkers. BSC1 ITMY ADC_3 23-25 => STS A 26-28 => STS B 29-31 => STS C BSC2 BS ADC_3 29-31 => STS A 23-25 => STS B 26-28 => STS C BSC3 ITMX ADC_3 26-28 => STS A 29-31 => STS B 23-25 => STS C That's right -- the channels have been cyclically rotated between BSC chambers. Electronics Chain: To test out which STS chassis maps to which GNDSTSINF (for ISIs) or STSINF (for HPIs), just in case the STS distribution chassis had been used to rectify the front-end badness, I toggled the period switch on the front of each of the three chassis, in consecutive order, and followed which channels showed the characteristic flip to (more) AC coupled signal (1 [sec] period) and then drove off into tilt land after switching back to the low-frequency mode (120 [sec] period). Since I didn't want to disconnect any cables, and couldn't simultaneously look at all the channels needed with the tiny laptop while zydeco dancing, all I could determine which which *rack* affected which GNDSTSINf or STSINF channel. (10) BSC 1 (ITMY) ISI and HPI on-board sensors are read out in rack SEI-C4, BSC2 (BS) ISI and HPI are read out in rack SEI-C5, and BSC3 (ITMX) ISI and HPI are read out by rack SEI-C6. As such, I'll refer to the STS chassis that I switch as C4, C5, and C6, after the rack in which they're mounted, since I was unable to determine which was HAM2 (STS A), Beer Garden (STS B), or HAM5 (STS C). (11) For the BSC-ISIs, the matrix of channels affected by the switching is as follows: ITMY BS ITMX C4 A A A C5 B B B C6 (bonkers) C C This indicates that, even though the ADC to model mapping is some crazy, cyclic thing, the cables from the STS distribution chassis have been arranged such that what goes into the ADC is "normal." The ITMY STS C channel doesn't make any sense to me. It didn't respond to any of the period-switch toggles, but still showed live tilt-full signals. Need to debug that one. (12) For the BSC-HPIs, it's different: ITMY BS ITMX C4 A B C C5 B C A C6 C A B This indicates, that the cabling matches the crazy-bonkers front-end mapping. (13) For the HAM-ISIs, it's different: HAM2 HAM3 HAM4 HAM5 HAM6 C4 A&B A (dead) (dead) A C5 (no change) B (dead) (dead) B C6 C C (dead) (dead) (no change) HAM2 is weird, but is consistent with the model layout described in (5b). HAMs 4 and 5 are receiving only ADC noise -- maybe this means the channels aren't hooked up? I didn't check. (14) And finally, the HAM-HEPIs, they're the worst off: HAM1 HAM2 HAM3 HAM4 HAM5 HAM6 C4 (n/c) A B (dead) (dead) (n/c) C5 (n/c) (n/c) (n/c) (n/c) (n/c) (n/c) C6 (n/c) (n/c) (n/c) (n/c) (n/c) (n/c) where "n/c" is not connected in the front-end model as described in (7a). Still no help as to why HAM4 and HAM5 are reading out ADC noise. And that's the anti-climactic end of the list. We've got some work to do! Step-one will be to update the SEI wiring diagrams to clearly define how each STS gets into each front-end via an ADC channel list. Next, change the top-level front end models to match the convention in the drawings. Third, change the cabling at the racks around so we get the expected behavior. At the moment, although it's don't in an icky way, the BSC-ISIs are our best case.
B. Abbott, J. Kissel Sorry for the belated post on this: I got a reply from B. Abbott on this, that is detailed enough that it should be put here for future reference. -------- Ben's reply --------- Looking at D0901301,, page 11 some things can be seen: In answer to item (12), i.e.: ITMY BS ITMX C4 A B C C5 B C A C6 C A B This is actually necessary, and had been planned as such. Each of the corner-station STS2s (HAM2, ITMY, and HAM5) are actually read out by the BSC chamber racks, i.e. the ITMX, BS, and ITMY chamber racks. These are the analog "home" where the STS is read out. Because the "Home" BSC chamber for each STS wants to bring in both the XYZ channels, and the UVW channels, the XYZ channels must come in to the local AA chassis on channels 23, 24 and 25, respectively (starting at channel 00, of course). That leaves the next STS-2 in the sequence to go into Ch26-28, and the next one to go into 29-31. This may not be optimal for ease of model-making, but it is necessitated by the desire for all six signals (which necessitates a 15-pin DSub cable). Looking at D1101576, Page 3, we see the HAM 2 (HAM3) mapping is: STS A on ADC0 (ADC2) Chs 24-27, STS B on ADC1 (ADC3) Chs 24-27, and STS C on ADC0 (ADC2) Chs 28-31. In D1000298, page 4, we see the analogous wiring to HAMs 2&3: the HAM 4 (HAM5) mapping is: STS A on ADC0 (ADC2) Chs 24-27, STS B on ADC1 (ADC3) Chs 24-27, and STS C on ADC0 (ADC2) Chs 28-31. Suggestions: (a) I like the way that HAMs 1&6 are hooked up, and suggest that we move all of the cables to match that mapping, with STS A coming in on ADC0 (or ADC2) Chs 24-27, STS B on ADC1 (or ADC3) Chs 24-27 and STS C on ADC1 (or ADC3) Chs 28-31. (b) I don't see any way to change the BSC mapping in the corner by moving cables, unless we fundamentally change the kind of cable (make a 15-9 pin converter) and don't care about the UVW channels. (c) I don't think there's much of any way to help out with the HEPI channels in hardware. I think this is solely a simulink model thing. ---------- End Ben's reply My thoughts on (a) and (c): I still have to do some research and talk with LLO on this. After conversing with Ryan DeRosa, he says "we have a functional system here!", so I want to make sure we don't re-invent the wheel and start another new convention before we write stuff down and change anything here at LHO. Regarding (b), fair enough. I had just forgotten about the need. But we at least need to make sure its consistent everywhere!
Alexa, Gabrielle, Kiwamu, Sheila
This morning we moved PRMI to the 3F sensors, we used a gain of 3 in the input matrix to move PRCL from REFL 9 I to REFL 27 I, and a gain of 15 to move MICH from REFL 45 Q to REFL 135 Q. This was locked from about 22:26:55 UTC (september 22) to 22:33:20.
We then tried to move on to DRMI but have struggled most of the day to get it locked. We locked it a few times this morning, (21:00 UTC) but haven't been able to recently.
Also, as is typical recently, the anthropogenic noise is higer durring the evenings than durring the day, there must be an evening shift of hanford work. Screen shot of the last week is attached. This pattern started in mid august and has been true since then.
After Sheila left, Jeff and I saw the DRMI locked for a minute or so at around 6:06 UTC. However, after this lock, the DRMI never caught a fringe again.
The settings at that point were:
Also, I experimentally had an off diagonal element of -1 in the REFL_A_RF9_I to SRCL element together with the usual REFL_A_RF45_I to SRCL element at that point. Since there was a 3 Hz oscillation in MICH when it was locked, I increased the MICH gain by a factor of three, but this did not help at all.
I did a quick comparison between the 'evening' (high BLRMS between 1 and 3 Hz as Sheila mentioned) and the 'night' (quiet time).
By looking at the ground, we do see some amplification in the spectrum around ~2.5Hz by almost a factor of 10. However, there is not a lot of power at those frequencies and this amplification doesn't seem to affect the optical lever motion (I looked at PR3).
I'll do a further analysis tomorrow and see what SUS and SEI are doing, but I wouldn't bet this is your issue so far.
I also don't think this is the reason we have not been locking DRMI, since th situation was similar on the nights we did lock, and the fringe speed is 1-2 fringes per second. It is just interesting that we are actually louder at night than durring the day.
On Sunday I took advantage of the interferometer downtime to make some improvements to the OMC scripts:
Also, last week I investigated a few bugs in the OMC PZT driver board:
One more thing: when I came in on Sunday the PZT HV supply was tripped. According to the EPICS readbacks this happened around 6:15am local time on Sunday (see attached). Not sure why this HV supply would trip by itself, but if you try to move the PZT and nothing happens, go check the HV...
There was a minor power bump at LHO around 0615 that would have caused this trip. Not all systems were bothered by this power anomaly. Only one of the UPS units bothered to report it so it must have been right around a threshold.
J. Kissel, K. Izumi, S. Biscans (Remotely) Through various back-channels, searching for reasons as to why the IFO is particularly noisy this evening, HAM2 and HAM3 ISI sensor correction came up in conversation. While we all thought the Sebastien had commissioned HAM2-ISI X sensor correction (see LHO aLOG 13964), yet we found that HAM2-ISI X sensor correction was OFF, and HAM3-ISI X sensor correction was ON, and has been ON with a gain of -0.5 since Thursday at ~3:30p PDT (1095114256, Sep 18 2014 22:24:00 UTC). Totally confused, we tried turning ON the the HAM2-ISI sensor correction, with the suggested gain of -10 from LHO aLOG 13964. This immediately caused the IFO to start shaking; clearly bad news. Naturally, given the level of confusion, we tried turning OFF HAM3 X sensor correction. I took long enough to write the above that Seb got back to us. (1) HAM2-ISI -- the correct gain is -1, not -10. Though -10 was originally correct, and what he used to get the performance measurments in LHO aLOG 13964, it was errant because the GNDSTSINF Cal filters, a gain of ~10, had not been installed on the HAM-ISIs. Unfortunately, he reported this info in the SEI aLOG, and didn't cross reference, so we didn't catch it. (2) HAM3-ISI -- Seb was teaching Jim and Hugh how to commission sensor correction using HAM3, and simple left what they had ON after Seb left Thursday afternoon. Seb is pretty confident that this correction is making things worse, so he recommends turning it OFF, and we have done so. PLEASE PLEASE PLEASE -- If you're working on ANYTHING to do with the IFOs at the sites, information should be reported first and foremost in that site's aLOG. You're more than welcome to link the entry to any other aLOG, or send it out on an email list, or send it it in a post card to your mom, but it MUST go in the site aLOG first. Sadly, after all the hub-bub, the IFO isn't working noticeably better. The investigation continues...
Peter, Sudarshan, Gabriele Today we installed the ISS second loop servo board and connected all the cables to the board itself and to the photodiodes. After some tweaks, we could get all the eight photodiodes showing some reasonable signals. The attached plot shows the signals measured on the eight photodiodes, still calibrated in counts. PD1-4 shows similar signals, although the gains seem to be different up to a factor 2. The same is true for PD5-8: they are quite similar one to the other. However, it seems that the signals on PD1-4 are a bit different from the signals on PD5-8. We also checked that the ISS QPD is cabled and working. As shown in the attached file, the QPD signals show some resonances at 1, 3.4 and 16 Hz, which are likely coming from motion of some optics. It is interesting to note that the same peaks are very well visible in all eight photodiodes. We don't know yet if the beam entering the ISS box is already intensity modulated at those frequencies, or if we have some jitter to intensity coupling at the ISS level. It seems that all PDs see the jitter peaks at a similar level, so the coupling should be in the common path. There is also very good coherence of all PDs with the QPD signals, at all frequencies below 10 Hz. We started investigating the transfer function of the transimpedance and whitening, to properly calibrate the signals in terms of dP/P. To be continued.
Although it seems like this should be unrelated to the ISS work, after the laser shut off this morning the FSS has been oscillating and the IMC has been very slow to lock after dropping. Peter and I lowered the FSS common gain to 27 dB.
B. Weaver, T. Sadecki, D. Sellers
Today we laced reaction chain cables and plugged in UIM and PenRe OSEMs. We then began another round of R0 TFs. TF results pending. Offsets and gains for the lower stages are as follows:
L1UL 19173 1.565 -9586
L1LL 27412 1.094 -13706
L1UR 24370 1.231 -12185
L1LR 23612 1.271 -11806
L2UL 22949 1.307 -11474
L2LL 24546 1.222 -12273
L2UR 24855 1.207 -12428
L2LR 23608 1.271 -11804
These have been loaded to MEDM.
We noted that the Q6 UIM L1 UL BOSEM was very low voltage. Today, Travis and Danny switched in a new one. We've updated the open light voltage offset and gain and loaded to MEDM.
After this change, now with serial numbers:
LOC SN OLV GAIN OFFSET L1UL 575 28826 1.041 -14413 L1LL 491 27412 1.094 -13706 L1UR 489 24370 1.231 -12185 L1LR 427 23612 1.271 -11806 L2UL 153 22949 1.307 -11474 L2LL 133 24546 1.222 -12273 L2UR 216 24855 1.207 -12428 L2LR 145 23608 1.271 -11804