Rather than using a CAD drawing, I used Gabriele's code from ELOG 9590 to try and judge if we could shorten the SRC by the appropriate length, without clipping the SR3-SR2 beam.
Specifically, I used these lines:
% Move SRM 7.5 towards SR2, parallel to beam
dAS = BS2-AS; % Vector from SRM to SR2
dASmag = sqrt(dAS(1)^2+dAS(2)^2);
dMove = delta*dAS/dASmag; % delta times unit vector
CS = CS+dMove;
As a reminder, Gabriele's code used the following logic:
In my opinion, this is the best estimate of beam trajectory that we currently have.
Thus, from looking at the plot above, I claim we can correct the SRC length without clipping the beam by moving the SRM forward by the required 7.5cm.
Although the measured distance may be off on the order of a cm (since our PRC correction had a 0.5cm disagreement between interferometric and hand distance measurements), this will nevertheless markedly improve our 3F DRMI sensing, based on my previous ELOG.
Hence, given our discussions last week, Jenne and I will proceed to ready the interferometer for venting in the morning, by following the vent checklist.
Our sole objective for this vent is this move of the SRM.
Steve, please check the jam nuts, and begin the vent when you get in. Thanks!
Since we'd like to get back to DRSE locking, I tried locking the DRMI tonight. I did the following:
GV 26 April 2017, 3pm: Forgot to note yesterday that I re-connected the suspect Satellite box, which has been connected to the SRM signal chain, back to the SRM suspension. I did not see any instances of glitching during my work last night. Also added pictures showing shifted spots on ITMs when PRC is locked relative to when arms are locked...
I got a couple of ~30min long DRMI lock stretches today. The settings I used are essentially the same as what I had back in November. Though we have since made some changes to the IMC RF signal chain, I guess it is not unreasonable that the LSC Demod phases that worked then work now as well.
In the lock stretches, I did the following:
On the side, I'm also looking at whether the PRC angular feedforward filters, last trained in October 2016, remain valid. Even post midnight, I am unable to lock the DRMI without turning on the FF, and looking at the POP QPD PIT and YAW signal spectra with the FF on vs FF off, there is definitely some improvement in the 1-4Hz band (plot to follow), question is whether we can do better and hence improve the DRMI duty cycle/ make the lock acquisition easier. To this end, I centered the beam on the POP QPD after locking and dither aligning the PRC on carrier, and have taken some data to look at.
So, much data analysis to follow - the idea is to put together a DRMI noise budget with Evan's NB code. For now, here are the uncalibrated control signal spectra.
one of these signals does not look like the others: explanation?
For the traces I posted, I had not turned on the whitening for the SRCL sensing PD (REFL55). However, I took a spectrum on a subsequent lock, with the analog whitening + digital dewhitening turned on for all 3 PDs (AS55, REFL11 and REFL55), and the HF part of the SRCL spectrum still looked anomalous. I'm putting together the detailed NB, but here's a comparison between the signals from the 3 RFPDs with the PSL shutter closed (but whitening engaged, and with the analog gains at the same values as used during the locking).
To convert the y-axis into m/rtHz, I used data from a sensing matrix measurement I took yesterday night during a DRMI lock - I turned on lines between 300 Hz and 325 Hz for the 3DOFs for ~5 minutes, downloaded the RFPD error signal data and did the demodulation. I used numbers from this elog to convert the actuator drive from cts to m. The final numbers I used were:
MICH (AS55_Q): 8.706 * 10^11 cts/m
PRCL (REFL11_I): 2.757 * 10^12 cts/m
SRCL (REFL55_I): 1.995 * 10^10 cts/m
So it looks like there may be something weird going on with the REFL55 signal chain. Looking at the LSC rack (and also suggested by an elog search), it looks like the demodulation is done by a demod board labelled "POP55" - moreover, the demodulated outputs are taken not from the regular output ports on this board, but from the "MON" ports on the front panel.
I took a closer look at the POP QPD/ PRC angular feedforward situation yesterday. I thought it would be useful to have a POP QPD MEDM screen. Looking at the PIT and YAW channel filter modules, the anti-whitening filters seemed different from what we have for other channels that are connected to the Pentek interface board (e.g. MCL). So I copied over the 150:15 (z:p) filter, and also turned on a 60Hz comb. The LSC offsets script does not set the dark offsets for this QPD, so I manually put in the dark offsets for the PIT, YAW and SUM channels as well. For the locking, I first locked the arms on IR an dither aligned them. Then I locked the PRMI on carrier, ran the PRC dither alignment, and went over to the ITMX pickoff table and centered the beam on the QPD by making the PIT and YAW channel timeseries oscillate around approximately zero.
After these tweaks, I collected ~40mins of data with the angular FF OFF/ON. I did not DC couple the ITM Oplev servos, but Eric tells me that this did not make a difference to the achievable subtraction in the past. Here is the frequency domain multicoherence analysis - I used the BS_X and BS_Y seismometer channels as witnesses. I've also put a plot with what the raw FF filter coefficients look like (no fitting yet).
Looks like we can do better for both DOFs - it even seems like we are injecting noise with the current FF filters in some bands, perhaps we can do a better job of rolling off the filters outside the band of interest. Eric and I were discussing MATLAB's "reduce" routine for this purpose, I will play around with it and see if I get a better fit.
Unfortunately, I encountered a strange error when trying to pull data with nds2 today, it kept complaining RuntimeError: Too many channels or too much data requested. even though I have pulled longer stretches of data for more channels with 16k sampling rate as recently as last week. Shorter duration requests (<600 seconds) seemed to work fine though... So I had to use cds.getdata to pull the data, and they're much too large to attach. Has anyone else encountered a similar error?
The mystery of the spots on the ITMs when the PRC is locked on carrier remains - after talking this over with Koji, we figured that even with the carrier resonant, the spot will be much dimmer than the spots when the arms are locked, but what I see on the cameras is still a pretty beefy spot. The real cavity mode is actually visible where it should be (I marked the locations of the spots with arms well-aligned with a marker on the monitors), as given away by some twinkling that is visible only when the cavity is locked. But what ghost beam is so intense it looks almost as bright as when the arm is locked?
GV 10pm 28 April 2017: Turns out this is the spot from the single bounce off the ETM transmitting back through the ITM and hitting the suspension cage (hence the bright spot). Johannes and I confirmed by moving the ETM, the spot moved with it. I just never paid attention to this spot before.
After tweaking the AS55 demod phase, SRM alignment, triggering settings, I got a few brief DRMI locks in tonight, I'm calling it a success (though this isn't really robust yet). The main things to do now are:
I think the main IFO characterization remaining to be done to determine the status of the IFO post vent is to measure the losses of the arm cavities. IMO, we will need to certainly fix the clipping at ETMY before we attempt some serious locking.
I've been playing around with Evan's NB code trying to put together a noise budget for the data collected during the DRMI locks last week. Here is what I have so far.
Attachment #1: Sensing matrix measurement.
Attachment #2: MICH OLTF measurement vs model
Attachment #3: Noise budget
I think I did the various conversions/calibrations/loop algebra correctly, but I may have overlooked something. Now that the framework for doing this is somewhat set up, I will try and put together analogous NBs for PRCL and SRCL.
GV 22 August 2017: Attachment #4 is the summary of my demod board efficiency investigations, useful for converting sensing measurement numbers from cts/m to W/m.
I attempted to re-lock the DRMI and try and realize some of the noise improvements we have identified. Summary elog, details to follow.
Basically after this point, I was unable to repeat stuff I did earlier in the evening just a couple of hours ago. The single arm locks catch quickly, and seem stable over the hour timescale, but when I run the X arm dither, the BS PITCH loop starts to oscillate at ~0.1 Hz. Moreover, I am unable to acquire PRMI carrier lock. I must have changed a setting somewhere that I am not catching right now (although I've scripted most of these things for repeatability, so I am at a loss what I'm missing ). The only change I can think of is that I changed the BS Oplev loop shape. But I went back into the filter file archives and restored these to their original configuration. Hopefully I'll have better luck figuring this out tomorrow.
I'm going to go squish cables and the usual sat. box voodoo, hopefully that settles it.
Since the single arm locking and dither alignment seemed to work alright after the CDS overhaul, I decided to try some recycling cavity locking tonight.
Why should this have changed? I was just on the AS table and did re-center the beam onto the REFL 55 RFPD, but I had also done this in April/May when I was last doing DRMI locking. But I can't explain the apparent factor of ~4 increase in light level. I think I have some measurements of the light levels at various PDs from April 2017, I will see how the present levels line up.
Of course dataviever won't cooperate when I am trying to monitor testpoints.
I may be missing something obvious, but I am quitting for tonight, will look into this more tomorrow.
Unrelated to this work: looking at the GTRY spot on the CCD monitor, there seems to be some excess angular motion. Not sure where this is coming from. In the past, this sort of problem has been symptomatic of something going wonky with the Oplev loops. But I took loop measurements for ITMY and ETMY PIT and YAW, they look normal. I will investigate further when I am doing some more ALS work.
I tried some DRMI locking again tonight, but had no success. Here is the story.
Looks like I will have to embark on the REFL55 LSC electronics investigation. I was able to successfully lock the PRC on carrier and sideband, and the Michelson lock also seems to work fine, all of which seem to point to a hardware problem with the REFL55 signal chain.
I did a quick check by switching the output of the REFL55 demod board to the inputs normally used by AS55 signals on the whitening board. Setting the whitening gain to +18dB for these channels had the same effect - ADC overflow galore. So looks like the whitening board isn't to blame. I will have to check the demod board out.
I wanted to recover the DRMI locking. Among other things, Jon mentioned that his mode spectroscopy can be done in the DRMI config. But I was foiled last night by a rogue waveplate in the AS beampath, and today evening, I noticed the resurfacing of this problem. Clearly, this is indicative of some issue in the analog whitening electronics, as the DC light level on the AS55 PD is consistent with previous measurements. Moreover, last time, the problem "fixed itself" so I don't know what exactly the problem was in the first place. I'll try doing the same test in the linked elog tomorrow. As a quick test, I cycled through the whitening gains (0-45dB) to see if it was some stuck ADC register, but that didn't fix the problem.
The problem seems to be with REFL55 only - I am able to lock the PRMI with carrier resonant without any issues, and the error signal levels are consistent with what I remember them being while the PRMI is swinging around. AS55 lives on the same whitening board and doesn't seem to suffer from the same probelms.
Decided to do the check tonight, but as Attachment #1 shows, no real red flags from the whitening gain side.
Given the various changes to the IFO config since last Thursday when I was last able to lock the DRMI, I wanted to try once again tonight. However, I had no success. By my judgement, the alignment is fine as judged by looking at mode flashes on the cameras. However, despite following the usual alignment procedures, I did not get a single lock in tonight.
Perhaps we can use a flip mount on the BS that combines the PSL and AUX beams on the AS table, so we have the option of recovering the usual IFO config when we so desire - while Jon needs the SRC locked for his measurement, it would be nice to not have to figure out the correct demod phases etc each time there is a change in the optical setup of the AUX beam.
I hadn't re-locked the DRMI after the work on the AS55 demod board. Tonight, I was able to recover the DRMI locking with the old settings.
The feature in the PRCL spectrum (uncalibrated, y-axis is cts/rtHz) at ~1.6kHz is mysterious, I wonder what that's about.
Wasted some time tonight futzing around with various settings because I couldn't catch a DRMI lock, thinking I may have to re-tune demod phases etc given that I've been mucking around the LSC rack a fair bit. But fortunately, the problem turned out to be that the correct feedforward filters were not enabled in the angular feedforward path (seems like these are not SDF monitored). Clue was that there was more angular motion of the POP spot on the CCD than I'm used to seeing, even in the PRMI carrier lock.
After fixing this, lock was acquired within seconds, and the locks are as robust as I remember them - I just broke one after ~20mins locked because I went into the lab. I've been putting off looking at this angular feedforward stuff and trying out some ideas rana suggested, seems like it can be really useful.
As part of the pre-lock work, I dither aligned arms, and then ran the PRCL/MICH dithers as well, following which I re-centered the ITM, PRM and BS Oplevspots onto their respective QPDs - they have not been centered for a couple of months now.
I'm now going to try and measure some other couplings like PSL RIN->MICH, Marconi phase noise->MICH etc.
I had some success today. I hope that the tweaks I made will allow working with the DRMI during the day as well, though it looks like the main limiting factor in lock duty cycle is angular stability of the PRC.
[Attachment #1]: Repeatable and reliable DRMI locks tonight, stability is mainly limited by angular glitches - I'm not sure yet if these are due to a suspect Oplev servo on the PRM, or if they're because of the tip-tilt PR2/PR3/SR2/SR3.
[Attachment #2]: A pass at measuring the TF from SRCL error point to MICH error point via control noise re-injection. I was trying to measure down to 40 Hz, but lost the lock, and am calling it for the night.
[Attachment #3]: Coherence between PRM oplev error point and beam spot motion on POP QPD.
Note that the MICH actuation is not necessarily optimally de-coupled by actuating on the PRM and SRM yet (i.e. the latter two elements of the LSC output matrix are not precisely tuned yet).
What is the correct way to make feedforward filters for this application? Swept-sine transfer function measurement? Or drive broadband noise at the SRCL error point and then do time-domain Wiener filter construction using SRCL error as the witness and MICH error as the target? Or some other technique? Does this even count as "feedforward" since the sensor is not truly "outside" the loop?
As it happened last time, the problem apparently fixed itself - somehow the act of me disconnecting the cables and reconnecting them seems to solve the problem, need to think about this.
Anyway, DRMI was locked a few times tonight. I got in a good long stretch where I ran some sensing lines and collected some data, analysis tomorrow. I am going to center the vertex oplevs as an alignment reference for now. A major source of lockloss seems to be angular instability - see for example this video grab of POP:
Could be due to noise injection from the noisy PRM Oplev HeNe, or just TT mirror angular motion (I couldn't get the PRC angular FF going tonight).
Pianosa just crashed and ate my elog, along with all the DTT/Foton windows I had open, so more details tomorrow... This workstation has been crashing ~once a month for the last 6 months.
Below ~100Hz, the hypothesis is that the BS oplev A2L contribution dominates the MICH displacement noise. I wanted to see if I could mitigate this my modifying the BS Oplev loop shape.
I've been banging my head against optimal loop shaping, with the OL loop as a test-case, without much success - as was the case with coating PSO, the magic is in smartly defining the cost function, but right now, my optimizer seems to be pushing most of the roots I'm making available for it to place to high frequencies. I've got a term in there that is supposed to guard against this, need to tweak further...
Attachment #2: Eye-fits of measured OL A2L coupling TFs to a 1/f^2 shape, with the gain being the parameter "fitted". I used these value, and the DQ-ed OL error signal in lock, to estimate the red curve labelled "A2L" in Attachment #1. The dots are the measurement, and the lines are the 1/f^2 estimates.
I have measured the sensing matrix of the DRMI although the lock still doesn't stay for a long time.
As for the noise budget, it looks very tough as there are more glitches than that in the PRMI.
In this weekend I will take some more trials in the DRMI lock until I am satisfied.
I've incorporated the functionality to generate sub-budgets for the various grouped traces in the NBs (e.g. the "A2L" trace is really the quadrature sum of the A2L coupling from 6 different angular servos).
For now, I'm only doing this for the A2L coupling, and the AUX length loop coupling groups. But I've set up the machinery in such a way that doing so for more groups is easy.
Here are the sub-budget plots for last night's lock - for the OL plot, there are only 3 lines (instead of 6) because I group the PIT and YAW contributions in the function that pulls the data from the nds server, and don't ever store these data series individually. This should be rectified, because part of the point of making these sub-budgets is to see if there is a particularly bad offender in a given group.
I'll do a quick OL loop noise budget for the ITM loops tomorrow.
I also wonder if it is necessary to measure the Oplev A2L coupling from lock to lock? This coupling will be dependant on the spot position on the optic, and though I run the dither alignment servos to minimize REFL_DC, AS_DC, I don't have any intuition for how the offset from center of optic varies from lock to lock, and if this is at all significant. I've been using a number from a measurement made in May. Need to do some algebra...
Approximately two weeks ago I diagonalized the LSC output matrix for the DRMI locking.
Since actuation on the position of BS changes not only MICH but also PRC and SRC, we needed to diagonalize the output matrix.
- What I did :
(1) The DRMI was locked. At this point PRC, MICH and SRC was controlled by PRM, BS and SRC actuators respectively.
(2) I injected excitation signal on C1:LSC-MICH_EXC by awg. The excitation was at about 200 Hz, which is above the UGF of all the LSC loops.
At this point the excitation only shakes the position of BS.
(3) I looked at spectra of REFL11_I, AS55_Q, AS55_I, that were used to sense PRC, MICH and SRC respectively.
At the beginning I was able to see the peak due to the excitation in those spectra. This means BS shakes the other DOFs (i.e. PRC and SRC) as well as MICH.
(4) To minimize the coupling from MICH to PRC (or SRC), I tuned a number on an element of the output matrix, which transfers the signal from MICH to PRM (or SRM).
This business was done by looking at the peak on REFL11_I (or AS55_I) and minimizing it. Since this technique was too naive the tuning was done only in second decimal place.
As a part of the DRMI preparation,
I leave all the suspensions free from the watchdogs for 5 hours from now.
Please DO NOT touch them.
I will check the spectra and the mechanical resonant frequencies on Monday.
Also I will renew all the input matrices of the local dampings based on these free swinging spectra.
I am not attempting a full characterization tonight, but the important changes since the May locks are in the de-whitening boards and coil driver boards. I did not attempt to engage the coil-dewhitening, but the PD whitening works fine.
As a quick check, I tested the hypothesis that the BS OL loop A2L coupling dominates between ~10-50Hz. The attached control signal spectra [Attachment #2] supports this hypothesis. Now to actually change the loop shape.
I've centered Oplevs of all vertex optics, and also the beams on the REFL and AS PDs. The ITMs and BS have been repeatedly aligned since re-installing their respective coil driver electronics, but the SRM alignment needed some adjustment of the bias sliders.
Full characterization to follow. Some things to check:
Lesson learnt: Don't try and change too many things at once!
GV July 5 1130am: Looks like the MICH loop gain wasn't set correctly when I took the attached spectra, seems like the bump around 300Hz was caused by this. On later locks, this feature wasn't present.
Basically we use the arm cavities as the reference of the beam alignment. The incident beam is aligned such that the ITMY angle dither is minimized (at least at the dither freq).
This means that we have no capability to adjust the spot poisitions on the PRM, SRM, BS, ITMX optics.
We are still able to minimize A2L by adding intentional asymmetry to the coil actuators.
After our Demod/Whitening electronics investigations suggested nothing obviously wrong, I decided to give DRMI locking another go tonight.
Surprisingly, there was no evidence of REFL55 behaving weirdly tonight, and I was able to easily lock the DRMI on 1f error signals using the recipe I've been using in the last few months.
Not sure what to make of all this .
I got in a ~15 minute lock, but I wasn't prepared to do any sort of characterization/ sensing / attempt to turn on coil-dewhitening, and I'm too tired to try again tonight. I was however able to whiten the error signals, as I have been able to do in the past. There is a ~45Hz bump in MICH that I haven't seen in the past.
I'll try and do some characterization tomorrow eve, but it's encouraging to at least get back to the pre-FB-failure state of locking.
Here are some preliminary results from the sensing sweeps I did the other night.
xml files, and DttData matlab script used to generate these plots is attached.
ARG, I accidentally permuted the digital demod angles. This significantly weakens the argument for believing AS55I is broken... In fact, Jenne and I did some investigations this afternoon that showed that the channel is indeed working. SRX error signal strangeness remains unexplained, however.
Also, I have yet to compensate for the gain of the violin filters; the actuator calibration numbers I used were for the SUS-LSC FMs, not the LSC FMs where I was injecting. New measurements will be taken soon, as well, since REFL165 is hopefully improved.
Corrected plots are below.
Here are a bunch of sensing signals. The configuration is always DRMI. Except for the optic noted in the title and the x-axis of any individual plot, other optics are held in their nominal position. DRMI condition is sidebands resonant in PRCL, 55MHz sideband resonant in SRCL. Each plot has an error signal, as well as the 2f signals at POP and AS.
The phases of POP22 and POP110 have been adjusted so that the I signal is maximized when everything is at the nominal positions (sideband resonant for PRMI). The phase of AS110 has been adjusted so that the I signal is maximized when the DRMI is in the nominal position (f2 resonant in SRC). The phases of the 1f1, 1f2, 2f1 and 2f2 REFL signals were all adjusted to have max PRCL signal in the I phase. AS55 was adjusted to have max SRCL signal in the Q phase.
Here is a time series when the DRMI is being locked.
You can see that the AS110 goes up because the SRCL is engaged and amplifies the 55 MHz sidebands.
(PRMI locking with slightly misaligned SRM)
First I tried locking PRC and MICH with a little bit misaligned SRM. This condition allowed me to search for a good signal port for SRC.
In this locking, REFL11_I was used to lock PRC and AS55_Q was used for MICH. This is the same scheme as the current PRMI locking.
Since the alignment of SRM was close to the good alignment, I expected to see fringes from SRC in some signal ports (i.e. REFL55, POY55 and so on).
Sometimes a fringe of SRC disturbed AS55_Q and broke the MICH locking, so I had to carefully misalign SRM so that the SRC fringes are small enough to maintain the lock of MICH.
(Looking for a good signal port for SRC)
After I locked the PRMI with slightly misaligned SRM, I started looking for a good signal port for SRC.
At the beginning I tried finding a good SRC port by shaking SRM at 100 Hz and looked at the power spectra of all the available LSC signals.
I was expecting to see a 100 Hz peak in the spectra, but this technique didn't work well because SRC wasn't within the linear range and hence didn't produce linear signals.
So I didn't see any strong signals at 100 Hz and finally gave up this technique.
Then I started looking for a PDH-like signal in time series and immediately found AS55_I showed large PDH-like signals.
So I started using the AS55_I for the SRC locking and eventually succeeded.
(Two tips for the DRMI locking)
During the locking of DRMI, I found two tips that made the locking quite smooth.
- Triggered locking
Since every LSC signal ports showed large signals from PRC somehow, feeding back the signals made the suspensions crazy.
So I used triggered locking for the PRC and MICH locking to avoid unwanted kicks on BS and PRM.
If the DC of REFL goes above a certain level, the control of PRC starts. Also if the DC of AS goes below a certain level the control of MICH starts.
These triggers make the lock smoother.
- Do not use resonant gain filters
This is really a stupid tip. When I was trying to lock MICH, the lock became quite difficult for some reasons.
It looked there was an oscillation at 3 Hz every time the MICH control started. It turned out that a 3 Hz resonant gain filter had been making it difficult.
All the resonant gain filters should be off when a lock acquisition is taken place.
Eventually the DRMI was locked.
More details will be reported in the morning.
I will try with POY55 that Koji prepared today.
I was struggling to find a good signal port for SRC over the weekend and finally found AS55_I worked somehow. I used :
REFL11_I --> PRC
AS55_Q --> MICH
AS55_I --> SRC
A configuration script was prepared such that someone can try this configuration by clicking a button on the C1IFO_CONFIGURE.adl screen.
I don't think this signal extraction scheme is the best, but now we can find better signal ports by shaking each DOF and looking at each signal port.
Given the RF component power supply grounding, POP110, POP22 and REFL165 all changed somewhat. They have all been rephased for the DRMI, as they were before.
I tweaked the 3F DRMI settings, and chose to phase REFL165I to PRCL, instead of SRCL as before, to try and minimize the PRCL->MICH coupling instead of the SRCL->MICH coupling.
With these settings, I once locked the DRMI for ~5 seconds with the arms held off on ALS, during which I could see some indications of neccesary demod angle changes. Haven't yet gotten longer, but we're getting there...
We are working on trying out the UGF servos, and wanted to take loop measurements with and without the servo to prove that it is working as expected. However, it seems like new DTT is not following the envelopes that we are giving it.
If we uncheck the "user" box, then it uses the amplitude that is given on the excitation tab. But, if we check user and select envelope, the amplitude will always be whatever number is the first amplitude requested in the envelope. If we change the first amplitude in the envelope, DTT will use that number for the new amplitude, so it is reading that file, but not doing the whole envelope thing correctly.
Thoughts? Is this a bug in new DTT, or a pebkac issue?
I took the output of the OMC DAC and plugged it directly into an OMC ADC channel to see if I could isolate the OMC DAC weirdness I'd been seeing. It looks like it may have something to do with DTT specifically.
Attachment 1 is a DTT transfer function of a BNC cable and some connectors (plus of course the AI and AA filters in the OMC system). It looks like this on both linux and solaris.
Attachment 2 is a transfer function using sweepTDS (in mDV), which uses TDS tools as the driver for interfacing with testpoints and DAQ channels.
Attachment 3 is a triggered time series, taken with DTT, of the same channels as used in the transfer functions, during a transfer function. I think this shows that the problem lies not with awg or tpman, but with how DTT is computing transfer functions.
I've tried soft reboots of the c1omc, which didn't work. Since the TDS version appears to work, I suspect the problem may actually be with DTT.
I am attempting to use the DTT program to look at the coherence of the individual accelerometer signals with the MC_L signal. Rana suggested that I might break up the XYZ configuration, so i wanted to see how the coherence changed when I moved things around over the past couple of weeks, but I keep getting a synchronization error every time I try to set the start time to more than about 3 days ago. I tried restarting the program and checking the "reconnect" option in the "Input" tab, neither of which made any kind of difference. I can access this data with no problem from the Data Viewer and the Matlab scripts, so I'm not really sure what is happening. Help?
EDIT: Problem solved - Full data was not stored for the time I needed to access it for DTT.
Seems like DTT also works now. The trick seems to be to run sudo /usr/bin/diaggui instead of just diaggui. So this is indicative of some conflict between the yum installed gds and the relic gds from our shared drive. I also have to manually change the NDS settings each time, probably there's a way to set all of this up in a more smooth way but I don't know what it is. awggui still doesn't get the correct channels, not sure where I can change the settings to fix that.
DON"T RUN DIAGGUI AS ROOT
I visited downs and announced that I would be showing up again until all the 40m hardware is delivered.
I brought over 4 ADC boards and 5 DAC boards which slot into the IO chassis.
The DACs are General Standards Corporation, PMC66-16AO16-16-F0-OF, PCIe4-PMC-0 adapters.
The ADCs are General Standards Corporation, PMC66-16AI6455A-64-50M, PCIe4-PMC-0 adapters.
These new ones have been placed with the blue and gold adapter boards, under the table behind the 1Y4-1Y5 racks.
With the 1 ADC and 1 DAC we already have, we now have enough to populated the two ends and the SUS IO chassis. We have sufficient Binary Output boards for the entire 40m setup. I'm going back with a full itemized list of our current equipment, and bring back the remainder of the ADC/DAC boards we're due. Apparently the ones which were bought for us are currently sitting in a test stand, so the ones I took today were from a different project, but they'll move the test stand ones to that project eventually.
I'm attempting to push them to finish testing the IO chassis and the remainder of those delivered as well.
I'd like to try setting up the SUS IO chassis and the related computer this week since we now have sufficient parts for it. I'd also like to move megatron to 1Y3, to free up space to place the correct computer and IO chassis where its currently residing.
Yesterday afternoon I went to downs and acquired the following materials:
2 100 ft long blue fibers, for use with the timing system. These need to be run from the timing switch in 1Y5/1Y6 area to the ends.
3 ADCs (PMC66-16AI6455A-64-50M) and 2 DACs (PMC66-16AO16-16-F0-OF), bringing our total of each to 8.
7 ADC adapter boards which go in the backs of the IO chassis, bringing our total for those (1 for each ADC) to 8.
There were no DAC adapter boards of the new style available. Jay asked Todd to build those in the next day or two (this was on Thursday), so hopefully by Monday we will have those.
Jay pointed out there are different styles of the Blue and Gold adapter boxes (for ADCs to DB44/37) for example. I'm re-examining the drawings of the system (although some drawings were never revised to the new system, so I'm trying to interpolate from the current system in some cases), to determine what adapter style and numbers we need. In any case, those do not appear to have been finished yet (there basically stuffed boards in a bag in Jay's office which need to be put into the actual boxes with face plates).
When I asked Rolf if I could take my remaining IO chassis, there was some back and forth between him and Jay about numbers they have and need for their test stands, and having some more built. He needs some, Jay needs some, and the 40m still needs 3. Some more are being built. Apparently when those are finished, I'll either get those, or the ones that were built for the 40m and are currently in test stands.
Aparently Friday afternoon (when we were all at Journal Club), Todd dropped off the 7 DAC adapter boards, so we have a full set of those.
Things still needed:
1) 3 IO chassis (2 Dolphin style for the LSC and IO, and 1 more small style for the South end station (new X)). We already have the East end station (new Y) and SUS chassis.
2) 2 50+ meter Ethernet cables and a router for the DAQ system. The Ethernet cables are to go from the end stations to 1Y5-ish, where the DAQ router will be located.
3) I still need to finish understanding the old drawings drawings to figure out what blue and gold adapter boxes are needed. At most 6 ADC, 3 DAC are necessary but it may be less, and the styles need to be determined.
4) 1 more computer for the South end station. If we're using Megatron as the new IO chassis, then we're set on computers. If we're not using Megatron in the new CDS system, then we'll need a IO computer as well. The answer to this tends to depend on if you ask Jay or Rolf.
I talked with Rolf, and asked if we were using Megatron for IO. The gist boiled down to we (the 40m) needed to use it for something, so yes, use it for the IO computer. In regards to the other end station computer, he said he just needed a couple of days to make sure it doesn't have anything on it they need and to free it up.
I had a chat with Jay where he explained exactly what boards and cables we need. Adapter boards are 95% of the way there. I'll be stopping by this afternoon to collect the last few I need (my error this morning, not Jays). However it looks like we're woefully short on cables and we'll have to make them. I also acquired 2 D080281 (Dsub 44 x2 to SCSI).
For each 2 Pentek DACs plus a 110B, you need 1 DAC adapter board (D080303 with 2 connectors for IDC40 and a SCSI). You also need a D080281 to plug onto the back of the Sander box (going to the 110Bs) to convert the D-sub 44 pins to SCSI.
LSC will need none, SUS will need 3, IO will need 1, and the ends will need 1 each. We have a total of 6, we're set on D080303s. We have 3 110Bs, so we need one more D080281 (Dsub44 to SCSI). I'll get that this afternoon.
For each XVME220, we'll need one D080478 binary adapter. We have 8 XVME220s, and we have 8 boards, so we're set on D08478s.
For the ends, there's a special ADC to DB44/37 adapter, which we only have 1 one of. I need to get them to make 1 more of these boxes.
We have 1 ADC to DB37 adapter, of which we'll need 1 more of as well, one for IO and one for SUS.
However, for each Pentek ADC, we need a IDC40 to DB37 cable. For each Pentek DAC we need an IDC40 to IDC40 cable. We need a SCSI cable for each 110B. I believe the current XVME220 cables plug directly in the BIO adapter boxes, so those are set.
So we need to make or acquire 11 IDC40 to DB37 cables, 7 IDC40 to IDC40 cables, and 3 SCSI cables.
I went to talk to Rolf and Jay this morning. I asked Rolf if a chassis was available, so he went over and disconnected one of his test stand chassis and gave it to me. It comes with a Contect DIO-1616L-PE Isolated Digital IO board and an OSS-MAX-EXP-ELB-C, which is a host interface board. The OSS board means it has to go into the south end station. There's a very short maximum cable length associated with that style, and the LSC and IOO chassis will be further than that from their computers (we have dolphin connectors on optical fiber for those connections).
I also asked Jay for another 4 port 37 d-sub ADC blue and gold adapter box, and he gave me the pieces. While over there, I took 2 flat back panels and punched them with approriate holes for the scsi connectors that I need to put in them. I still need to drill 4 holes in two chassis to mount the boards, and then a bit of screwing. Shouldn't take more than an hour to put them both together. At that point, we should have all the adapter boxes necessary for the base design. We still need some stuff for the green locking, as noted on Friday.
After talking with Rolf, and clarifying exactly which machine I wanted, he gave me an 4600 Sun machine (similar to our current megatron). I'm currently trying to find a good final place for it, but its at least here at the 40m.
I also acquired 3 boards to plug our current VMIPMC 5565 RFM cards into, so they can be installed in the IO chassis. These require +/- 5V power be connected to the top of the RFM board, which would be not possible in the 1U computers, so they have to go in the chassis. These style boards prevent the top of the chassis from being put on (not that Rolf or Jay have given me tops for the chassis). I'm planning on using the RFM cards from the East End FE, the LSC FE, and the ASC FE.
I talked to Jay, and offered to upgrade the old megatron IO chassis myself if that would speed things up. They have most of the parts, the only question being if Rolf has an extra timing board to put in it. Todd is putting together a set of instructions on how to put the IO chassis together and he said he'd give me a copy tomorrow or Monday. I'm currently planning on assembling it on Monday. At that point I only need 1 more IO chassis from Rolf.
When I asked about the dolphin IO chassis, he said we're not planning on using dolphin connections between the chassis and computer anymore. Apparently there was some long distance telecon with the dolphin people and they said the Dolphin IO chassis connection and RFM doesn't well together (or something like that - it wasn't very clear from Rolf's description). Anyways, the other style apparently is now made in a fiber connected version (they weren't a year ago apparently), so he's ordered one. When I asked why only 1 and what about the IOO computer and chassis, he said that would either require moving the computer/chassis closer or getting another fiber connection (not cheap).
So the current thought I hashed out with Rolf briefly was:
We use one of the thin 1U computers and place that in the 1Y2 rack, to become the IOO machine. This lets us avoid needing a fiber. Megatron becomes the LSC/OAF machine, either staying in 1Y3 or possibly moving to 1Y4 depending on the maximum length of dolphin connection because LSC and the SUS machine are still supposed to be connected via the Dolphin switch, to test that topology.
I'm currently working on an update to my CDS diagram with these changes and will attach it to this post later today.
I picked up the ribbon cable connectors from Jay. It looks like we'll have to make the new cables for connecting the ADCs/DACs myself (or maybe with some help). We should be able to make enough ribbon cables for use now. However, I'm adding "Make nice shielded cables" to my long term to do list.
I pointed out the 2 missing adapter boxes we need to Jay. He has the parts (I saw them) and will try to get someone to put it together in the next day or so. I also picked up 2 more D080281 (DB44 to SCSI), giving us enough of those.
I once again asked Jay for an update on IO chassis, and expressed concern that without them the CDS effort can't really go forward, and that we really need this to come together ASAP. He said they still need to make 3 new ones for us.
So we're still waiting on a computer, 3 IO chassis, router + ethernet.
Talked with Jay briefly this morning.
We are due another 1-U 4 core (8 CPU) machine, which is one of the ones currently in the test stand. I'm hoping sometime this week I can convince Alex to help me remove it from said test stand.
The megatron machine we have is definitely going to be used in the 40m upgrade (to answer a question of Rana's from last Wednesday's meeting). Thats apparently the only machine of that class we get, so moving it to the vertex for use as the LSC or SUS vertex machine may make sense. Overall we'll have the ASS, OMC, Megatron (SUS?), along with the new 4 1-U machines, for LSC, IO, End Y and End X. We are getting 4 more IO chassis, for a total 5. ASS and OMC machine will be going without full new chassis.
Speaking of IO chassis, they are still being worked on. Still need a few cards put in and some wiring work done. I also didn't see any other adapter boards finished either.
Talked with Jay briefly today. Apparently there are 3 IO chassis currently on the test stand at Downs and undergoing testing (or at least they were when Alex and Rolf were around). They are being tested to determine which slots refer to which ADC, among other things. Apparently the numbering scheme isn't as simple as 0 on the left, and going 1,2,3,4, etc. As Rolf and Alex are away this week, it is unlikely we'll get them before their return date.
Two other chassis (which apparently is one more than the last time I talked with Jay), are still missing cards for communicating between the computer and the IO chassis, although Gary thinks I may have taken them with me in a box. I've done a look of all the CDS stuff I know of here at the 40m and have not seen the cards. I'll be checking in with him tomorrow to figure out when (and if) I have the the cards needed.