40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 248 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  11349   Tue Jun 9 10:57:12 2015 SteveUpdateSUS BS oplev laser tuned

Lenses removed from oplev beam path at elog entry 11246

 

  11350   Wed Jun 10 02:50:39 2015 ericqUpdatePEMWilcoxon Accelerometer Huddle Test

Here are some results for the 3-corner hat subtraction for the six accelerometers, from ~1 hour of data that didn't look to have any sharp features/glitches from human activity in the lab. 

I used the python uncertainties package to try and get an estimate of the uncertainty in the subtracted noise floor, by taking into account every possible possible combination of 3 sensors and the fluctuations in the spectrograms of the subtracted signals. I've attached the python code if anyone is interested in the implementation. 

I pulled out the accelerometer data sheets to read their slightly varying V/g calibration (which differs on the order of a few percent from unit to unit). This improved the subtraction factor from ~20 to over 100 at some frequencies. I've edited the filter modules such that the OUT_DQ channels are already calibrated into m/s^2.

  11351   Wed Jun 10 03:19:58 2015 ericqUpdateLSCAUX PDH error measured in CDS

Looking over the old noise budget in the green locking paper, it seems the main technical noise sources were the AUX PDH error and DFD noise. I'm working on quantifying the current state of these noises. 

Rather than lugging out the analyzers every time I wanted to make a measurement of the AUX PDH error signals, I set out to make the existing digitized channels (ALS-[X/Y]_ERR_MON) usable for easier, and continuous, monitoring. Sadly, up until now the signals were poorly conditioned, and drowning in ADC noise. (When locked, the Y error signal was only +-10 counts!)

Of course, given the bandwidth of the green servos (10kHz), this won't tell us the full story of the what the green PDH lock is doing, but does indicate how much residual frequency noise exists in the ALS control band. 

I'm currently using SR560s at G=20 at each end to amplify the ERR MON outputs of the uPDH boards before sending them to the ADCs; now that I've found a gain that works, I'll modify the error point monitor buffer opamps inside the uPDH boards themselves during the daytime. 

The AUX Y error signal was going into an AA board with some funky filtering going on that I didn't want to mess with. Instead, I've moved the signal to the pentek generic board whose first four channels are used for the oplev segments, and the second quartet are unused, save for the TST channel I hooked up yesterday. 

On the pentek board, I changed the 4th order 800Hz lowpass to a 4th order 8kHz lowpass on the last three channels through some resistor swapping. (At first it was just the last two, but I found I was getting weird signals in the 32nd channel; and if I recall correctly from my cymac work, the 32 ADC channel is used for some timing signal or something...). I also turned off the 1:10 whitening filters on the last four channels via PCB jumper. 

I then unhooked the PZT drive and let the PDH error signals swing around, to calibrate the ADC counts into HZ. Now, the ALS-[X/Y]_ERR_MON_OUT_DQ are calibrated in green Hz! Here are the spectra.

As we've seen in the past (ELOG 10464), the X green is limited by the dark noise of the PD from 10-100Hz. This isn't so great. The RMS noise from 300Hz downwards (which is maybe the band where the ALS control would inject noise into the mirror motion) is about Y:10Hz X:40Hz.

During this time, the test masses were not under any longnitudinal control, so I'm not sure why there is such a difference in the height of the suspension resonance peaks, unless there's some differene in the low frequency PDH TFs that I've forgotten about. 

Now, with these references, we can easily check if the PDH loops change qualitatively over longer time periods.

I'll be including the effect of these noises in the upcoming revised ALS noise budget.

  11352   Wed Jun 10 15:54:14 2015 SteveUpdateVACVacuum comp. rebooted

Koji and Steve succeded rebooting C1vac1, C1vac2 and pressure reading is working now

More tomorrow .........

 

  11353   Thu Jun 11 19:40:59 2015 KojiUpdateVACVacuum comp. rebooted

The serial connections to the vacuum gauges were recovered by rebooting c1vac1 and c1vac2.

Steve claimed that the vacuum screen had showed "NO COMM" at the vacuum pressure values.
The epics connection to c1vac was fine. We could logged in to c1vac1 with telnet too although c1vac2 had no response.

After some inspection, we decided to reboot the slow machines. Steve manually XXXed YYY valves (to be described)
to prepare for any possible unwanted switching. Initially Koji thought only c1vac2 can be rebooted. But it was wrong.
If the reset button is pushed, all of the modules on the same crate is reset. So everything was reset. After ~3min we still
don't have the connection to c1vac1 restored. We decided to another reboot. This time I pushed c1vac1 reset button.
After waiting about two minutes, the ADCs started to show green lights and the switch box started scanning.
We recovered the telnet connection to c1vac1 and epics functions. c1vac2 is still note responding to telnet, and
the values associated with c1vac2 are still blank.

Steve restored the valves and everything was back to normal.

  11354   Fri Jun 12 08:40:17 2015 SteveUpdateVACVacuum comp. rebooted

Koji and Steve,

One computer expert and one vacuum expert required.

Quote:

The serial connections to the vacuum gauges were recovered by rebooting c1vac1 and c1vac2.

Steve claimed that the vacuum screen had showed "NO COMM" at the vacuum pressure values.
The epics connection to c1vac was fine. We could logged in to c1vac1 with telnet too although c1vac2 had no response.

After some inspection, we decided to reboot the slow machines. Steve manually XXXed YYY valves (to be described)
to prepare for any possible unwanted switching. Initially Koji thought only c1vac2 can be rebooted. But it was wrong.
If the reset button is pushed, all of the modules on the same crate is reset. So everything was reset. After ~3min we still
don't have the connection to c1vac1 restored. We decided to another reboot. This time I pushed c1vac1 reset button.
After waiting about two minutes, the ADCs started to show green lights and the switch box started scanning.
We recovered the telnet connection to c1vac1 and epics functions. c1vac2 is still note responding to telnet, and
the values associated with c1vac2 are still blank.

Steve restored the valves and everything was back to normal.

Atm 1,  problem condition: gauges are not reading for a week, error message "NO COMM" and all computer LEDs are green

Atm 2, prepare to safe reboot:

            a, close V1, disconnect it's power cable and turn off Maglev, wait till rotation stops

            b, close PSL shutter ( take adrenaline if needed )

            c, close V4, V5, VA6 valves and disconnect their cables. "Moving" error message indicating this condition.

               V1 is not showing "Moving" because its power cable disconnected only! It will show it if its position indicator cable is disconnected too. There is no need for that.

               These valves closed and disabled will not allow accidental venting of main volume.

            d, push reset, reseting c1vac2 will reset c1vac1 also, wait ~ 6 minutes

"Vacuum Normal" valve configuration was restored after succesful reboot as follows:

             a, reconnect cable and open V4 and V5 at P2 & P3 <1e-1 Torr

             b, observe that P2  < 1e-3 Torr and retsart Maglev

             c, wait till Maglev reaches full speed of 560 Hz and reconnect-open V1

             d, reconnect-open VA6 at P3 <1e-3 Torr

NOTE: VM1 valve was locked in open position and it was not responding before and after reboot

          Error message on Atm2 is indicating this locked condition: "opening VM1 will vent IFO"

          This is a fauls message. The valve is frozen in open position. We need a softwear expert help.

 

 

  11355   Fri Jun 12 17:09:58 2015 ericqUpdateLSCBeatbox needs whitening gain

Short entry just to preview a new development; more detail about this investigation will soon follow. 

The beatbox I and Q signals are too small at the ADC! I was able to reduce the RMS out of loop ALS sensitivity (arm locked on POX) by 300Hz with G=10 SR560s between the beatbox output and the ADC whitening chassis input. Increasing the beat note amplitude via RF amplifier had no positive effect. 

There is still a reasonable gap between this and the beatbox's noise levels, as measured with a marconi. There may be additional headroom for whitening gain; the SR560 maximum output range is smaller than the ADC input range. 

The high frequency noise has >0.5 coherence with the PDH error signal above a kHz or so, but not much below that. 

We should probably either modify the output whitening of the beatbox, or introduce some (variable?) whitening gain in a seperate circuit. 

  11356   Sat Jun 13 18:37:46 2015 ericqUpdateLSCBeatbox needs whitening gain

Here are the promised details!

I was worried about the lack of whitening gain, as I saw that the DC phase tracker Q output (which is the magnitude of the signal in the beatbox's I-Q plane) was no more than 200 ADC counts for X (~120mV), and 800 for Y (~500mV). I.e. this is the largest DC value that either the I or Q ADC channels can see, and the RMS fluctuations are on the order of mV, meaning we're wasting our entire ADC rangeno

However, I also had doubts about this since, even in the nominal state, the ASD of the ADC signals before dewhitening was higher than the expected ADC noise level. However, because of the non-linearity of the conversion of the BEAT_I and Q signals into the phase tracker output, evaluating the contribution of the beatbox output and ADC input voltage noises takes a few more steps. 

So, I hooked up a Marconi as the signal source for the beatbox's X channel , with no modulation (presumably the phase noise of the Marconi output is significantly lower than the sensitivity of the beatbox). For all of these measurements, the beat frequency was kept around 50MHz, with an amplitude of -30dBm on the control room analyzer, which is a typical X ALS operating point. 

At this point, the beatbox output noise was below the ADC noise (as measured by an SR785). Nevertheless, I found that the beat spectrum driven by the Marconi lined up to be very close to the ALS beat spectrum across a wide band, explaining much of the noise. 

At this point, I inserted SR560s in between the beatbox I and Q outputs, and the AA chassis leading to the ADC. A gain of 10 reduced the resultant phase tracker noise by that same factor at nearly all frequencies. A further increase in gain did not lead to the noise changing appreciably, probably because the real beatbox noise was now contributing, as is suggested by some common peaks in the direct beatbox output phase tracker spectra.

Going back to the real green beat signal with the SR560s still at G=10, I obtained the result shown in ELOG 11355. I will soon repeat this process with the Y ALS. 

As I mentioned in the previous ELOG, we may be further helped by more whitening gain than can be provided by the SR560s (and we obviously need a robust long term circuit for this gain). If it then turns out we are limited by beatbox noise to a degree we are not happy with, we could perhaps look into reintroducing some RF gain into the X beat. As Koji mentions in ELOG 8855, the beatbox operates best at an RF input of around -4dBm.

  11357   Sat Jun 13 23:52:14 2015 ericqUpdateLSCBeatbox needs whitening gain

Nice find!

We ought to use our noise model of the ALS signal chain to determine what the right gains are, rather than hunt and peck. More likely we'll start from the right gains.​

Once the gains and/or whitening filters make sense, maybe we'll see some effect from fixing the green PDH loops.

  11358   Mon Jun 15 11:54:44 2015 ericqUpdateCDSParts not in SVN

I ran the following command to find which models/parts are not under version control, or have modifications not commited:

grep "mdl" $(cat models.txt) | awk '{print $NF}' | sort | uniq | xargs svn status

models.txt includes lines like "/opt/rtcds/caltech/c1/rtbuild/c1ass.log" for each running model. These are the build logs that detail every file being sourced. 

The resultant list is:

?       /opt/rtcds/userapps/release/cds/common/models/BLRMS_HIGHFREQ.mdl
C       /opt/rtcds/userapps/release/cds/common/models/rtdemod.mdl
M       /opt/rtcds/userapps/release/cds/common/models/SCHMITTTRIGGER.mdl
?       /opt/rtcds/userapps/release/isc/c1/models/blrms.mdl
?       /opt/rtcds/userapps/release/isc/c1/models/IQLOCK.mdl
?       /opt/rtcds/userapps/release/isc/c1/models/PHASEROT.mdl
?       /opt/rtcds/userapps/release/sus/c1/models/QPD_WHITE_CTRL_MUX.mdl

I will commit the uncommited c1 parts, and think about what to do about the rtdemod and SCHMITTRIGGER parts. 

Once I check out the latest revision of the userapps repo (in a seperate location), I will do something similar to look for models that have changed since the svn revision that is checked out in our running system. 

  11359   Mon Jun 15 16:55:39 2015 ericqUpdatePEMAccelerometers installed

The accelerometers have been installed at MC1 and MC2. MC2 data is live, I haven't yet run the cables from the MC1 set to the preamp yet, though. 

  11360   Mon Jun 15 20:36:48 2015 ranaUpdateIOOIOO QPDs centred

after re-aligning the beam into the PMC, I touched up the steering mirros into the IOO QPDs so that the beams are now centered again. Please don't adjust these references without prior authorization and training.

This plot shows the 10-minute trends for these QPDs over the last 400 days.

  11361   Mon Jun 15 22:36:40 2015 rana, kojiUpdateGreen LockingBeatBox Assay: not looking good

Because the ALS beatbox schematic is out-of-date and misleading, we pulled the box to photograph the current implementation and figure out how to proceed. The box is out on the EE bench right now. Schematic Doc added to 40m Document tree: https://dcc.ligo.org/LIGO-D1102241. Some notes:

  1. The soldering on this board is pretty messy and there are a lot of flying wire and flying component hacks. I wouldn't trust all of the connections.
  2. The GV-81 RF amps in the front end are both stuffed. The 1 dB compression point is 19 dBm, so we want to use them below 10 dBm output. They have a gain of +10.5 dB, so that means they should not be used with and input to the beatbox of more than -10 dBm. Otherwise there will be nonlinear noise generation.
  3. Not stuffed: U1-Comparator, A1-attenuator, U2-splitter.
  4. Why is the filter after the mixer only 2nd order?? That's not a valid filter choice in any RF world. How much do we want to cut off the 2f mixer output before sending into our low noise, audio frequency (and prone to downconversion) amplifier? The Mini-Circuits amplifiers would have given us >60 dB attenuation in the stop band. This one is only going to give us 20-30 dB when the beat frequency is low. Get rid of diplexer. The schematic claims that its just one pole?? Seems like a 2nd order LP filter to me.
  5. The modified schematic (see Koji elog 8855) shows that an OP27 is used for the whitening stage. The current noise of the OP27 with the 3k resistor makes the OP27 current noise dominate below 1 Hz. And what is going on with that filter capacitor choice? We never want to use these tiny things for sensitive filter applications. (cf. Sigg doc on resistor and capacitor choice, the noise reduction book by Ott, H&H, etc.). That's why we have the larger metal-poly, paper, mylar, etc. caps sitting around.

Probably we ought to install a little daughter board to avoid having to keep hacking this dead horse. Koji has some of Haixing'g maglev filter boards. Meanwhile Koji is going to make us a new beatbox circuit in Altium and we can start fresh later this summer.

Interesting link on new SMD cap technology.

Photos of circuit as found

  11362   Wed Jun 17 15:31:50 2015 ericqUpdatePEMAccelerometers fully installed

MC1 accelerometer has been plugged in. The modecleaner locking has been intermittent today, but I looked at a 15 minute lock in DTT, looking at the STS1 seismometer and both accelerometer triplets. Plot and DTT xml attached.

For the sake of not cluttering up everything with legends, the coherence plots are organized by direction (x, y, z), and include the coherence of each of the three sensors (sts, acc1, acc2) with the IMC control signal and the IMC transmitted RIN. 

Some remarks:

  • The 1 Hz pendulum motion is about equal amounts of X and Y, which makes sense, as MC1 and 3 are at an angle
  • The ~3 Hz stack motion seems to be entirely in the X direction. Why?
  • The bounce/roll bands are strongly coherent with Z motion at MC2. 
  • The STS does not appear to have any low frequency advantage over the accelerometers, in terms of coherence, contrary to what I would expect even without a thermal enclosure. 
  • The control signal and RIN RMSs are clearly dominated by noise in the 1-3Hz band, where we have reasonable coherence. Good prospects for noise subtraction...

  11363   Fri Jun 19 01:24:26 2015 rana, kojiUpdateGreen LockingBeatBox Assay: not looking good

We had decided a few days ago, to bypass the IF part of the BeatBox board and put some of the Haixing Maglev generic filter boards in there so that we could get more whitening and also have it be low noise.

Tonight we wondered if we can ditch the whole BeatBox and just use the quad aLIGO demod box (D0902745) that Rich gave us a few years ago. Seems like it can.

But, it has no whitening. Can we do the whitening part externally? Perhaps we can run the RF signals from the output of the beat RF Amps over to the LSC rack and then put the outputs into the LSC Whitening board and acquire the signals in the LSC ?

  11364   Fri Jun 19 01:55:35 2015 ericqUpdateGreen LockingBeatBox Assay: not looking good
Quote:

But, it has no whitening. Can we do the whitening part externally? Perhaps we can run the RF signals from the output of the beat RF Amps over to the LSC rack and then put the outputs into the LSC Whitening board and acquire the signals in the LSC ?

I like this idea; it gives us more control over the whitening, and saves the IPC delay. We could use the currently vacant AS165 and POP55 channels. 

We'd only have to move the phase trackers to c1lsc, which means 12 more FMs total. This is really the only part of the c1als model our current system uses, the rest is from before the ALS->LSC integration. 

  11365   Fri Jun 19 03:00:56 2015 ericqUpdateCDSLibrary Model Parts examined

All simulink diagrams being used at the 40m are now under version control. I have compiled, installed, and restarted all current models to make sure that the files are all in a working state, which they seem to be. I have checked the latest version of the userapps svn repository to /opt/rtcds/userapps2.9, to compare the files therein with our current state. 

Surprisingly, only two files in the userapps svn have been changed since they were checked out here, and only one of these is a real change of any kind. 

LSC_TRIGGER.mdl was edited at some point simply to align some drawn lines; no functionality was changed. 

SCHMITTTRIGGER.mdl was edited to change the "INVERT" epics channel from an arbitrary EPICS input, to binary (true/false) input. This does not change the connectivity diagram, and in fact, I don't think we use this option in any of our scripts, nor is it exposed on our medm screens. 

Thus, I think that the only place for block changes can bite us is changes in the fundamental blocks in CDS_PARTS that are used in our custom 40m library parts. 

For posterity, these are the files used in compiling all of our running models. (Path base: /opt/rtcds/userapps/release)

/isc/common/models/CALIBRATION.mdl
/isc/common/models/FILTBANK_TRIGGER.mdl
/isc/common/models/LSC_TRIGGER.mdl
/isc/common/models/QPD.mdl
/cds/common/models/FILTBANK_MASK.mdl
/cds/common/models/lockin.mdl
/cds/common/models/rtbitget.mdl
/cds/common/models/rtdemod.mdl
/cds/common/models/SCHMITTTRIGGER.mdl
/cds/common/models/SQRT_SWITCH.mdl
/cds/c1/models/c1rfm.mdl
/cds/c1/models/c1tst.mdl
/cds/c1/models/c1x01.mdl
/cds/c1/models/c1x02.mdl
/cds/c1/models/c1x03.mdl
/cds/c1/models/c1x04.mdl
/cds/c1/models/c1x05.mdl
/isc/c1/models/ALS_END.mdl
/isc/c1/models/BLRMS_40M.mdl
/isc/c1/models/BLRMS_HIGHFREQ.mdl
/isc/c1/models/blrms.mdl
/isc/c1/models/c1als.mdl
/isc/c1/models/c1ass.mdl
/isc/c1/models/c1asx.mdl
/isc/c1/models/c1cal.mdl
/isc/c1/models/c1ioo.mdl
/isc/c1/models/c1lsc.mdl
/isc/c1/models/c1oaf.mdl
/isc/c1/models/c1pem.mdl
/isc/c1/models/IQLOCK.mdl
/isc/c1/models/IQ_TO_MAGPHASE.mdl
/isc/c1/models/PHASEROT.mdl
/isc/c1/models/RF_PD_WITH_WHITENING_TRIGGERING.mdl
/isc/c1/models/SENSMAT_LOCKINS.mdl
/isc/c1/models/TT_CONTROL.mdl
/isc/c1/models/UGF_SERVO_40m.mdl
/sus/c1/models/c1mcs.mdl
/sus/c1/models/c1scx.mdl
/sus/c1/models/c1scy.mdl
/sus/c1/models/c1sus.mdl
/sus/c1/models/lib/sus_single_control.mdl
/sus/c1/models/QPD_WHITE_CTRL_MUX.mdl
  11366   Fri Jun 19 16:54:20 2015 JenneUpdateComputer Scripts / ProgramsWiener scripts in scripts directory

I have put the Wiener filter scripts into  /opt/rtcds/caltech/c1/scripts/Wiener/  .  They are under version control. 

The idea is that you should copy ParameterFile_Example.m into your own directory, and modify parameters at the top of the file, and then when you run that script, it will output fitted filters ready to go into Foton.  (Obviously you must check before actually implementing them that you're happy with the efficacy and fits of the filters). 

Things to be edited in the ParameterFile include:

  • Channel names for the witness sensors (which should each have a corresponding .txt file with the raw data)
  • Channel name for the target
  • Folder where this raw data is saved
  • Folder to save results
  • 1 or 0 to determine if need to load and downsample the raw data, or if can use pre-downsampled data
    • This should probably be changed to just look to see if the pre-downsampled data already exists, and if not, do the downsampling
  • 1 or 0 to determine if should use actuator pre-weighting
  • Data folder for measured actuator TFs (only if using actuator pre-weighting)
    • Actuator TFs can be many different exported text files from DTT, and they will be stitched together to make one set of measurements, where all points have coherence above some quantity (that you set in the ParameterFile)
  • Coherence threshold for actuator data (only use data points with coherence above this amount)
  • Fit order for actuator transfer function's vectfit
  • 1 or 0 to decide if should use preweighting filter
  • zeros and poles for preweighting filters
  • 1 or 0 to decide if should use lowpass after Wiener filters (will be provided corresponding SOS coefficients for this filter, if you say yes)
  • Lowpass filter parameters: cuttoff freq, order and ripple for the Cheby filter
  • New sample rate for the data
  • Number of Wiener filter taps
  • Decide if use brute force matrix inversion or Levinson method
  • Calibrations for witnesses and target
  • Fit order for each of the Wiener filters

I think that's everything that is required.

  •  
  11367   Sun Jun 21 13:21:03 2015 ranaUpdatePEMWilcoxon Accelerometer Huddle Test

To improve our sensor noise estimate, the ACC cables should be clamped using a rubber pad and a big dog clamp on the SP tabletop before exiting the table. Also the sensors themselves should be covered with a foam box or a double cardboard box. The high-frequency acoustic noise may limit the 10 Hz performance since piezos are not very linear.

Quote:

I've set up the Wilcoxen accelerometers on the SP table for a huddle test, to estimate their noise levels. 

They're clamped down to the table along the same axis, and their housings are in good contact, in hopes to make them as correlated as possible. 

Wilcoxon. Not Wilconox or Wilco or Wilcoxen. Have some pity on future keyword searchers.

  11371   Mon Jun 22 20:59:19 2015 ericqUpdateLSCDFD Delay length

I've been thinking a bit about what the ideal cable length / delay time for the upgraded ALS beatbox should be. Here are some thoughts, but no conclusions yet. 

If you're not running your beatbox mixer in compression, there are two competing effects when you change the cable length. At first, more delay gives better sensitivity, but this does not go on to infinity, because cable attenuation eventually kills your signal. It turns out that the ideal length can be derived to be whatever length gives you 20/ln(10) = -8.7dB of attenuation. Frank found this out in PSL ELOG 825, and I found an HP document that derives this (and other useful DFD math) to the wiki, here.

In PSL ELOG 826, Frank calculated this ideal length for a 160MHz carrier in various kinds of cables. 

However, this is not the end of the story. In the case of the DFD, we actually benefit from operating the mixer in compression, as makes our sensitivity less sensitive to flucuations in the beat amplitude. In this situation, the HP doc states "For maximum sensitivity, more delay can be added until the signal level out of the delay line is 8.7dB below the phase detector (mixer) compression point." I'm not sure I really understand the logic behind this statement, though. 

Lastly, Koji mentioned the fact that the splitter in the demod board does not split at exactly 90 degrees, making the trajectory in the IQ plane an ellipse. This means that if the beat signal is moving around the ellipse a lot, or even wrapping around it, we can suffer from some nonlinear signal conversion. Also, if the raw DFD sensitivity is very high, the free swinging mirrors will cause the signal to swing around faster than the phase tracker can keep up. This should be easy to avoid, however; I doubt we will use so much cable that the beat would move by so much. 

I intend to take all of this into account when picking a cable length! Jessica is going to help us make a nice box for them, too. 

  11372   Tue Jun 23 11:18:20 2015 SteveUpdatePEMcleaning around chambers

Keven is our regular janitor is out for a few weeks.

The sub is careful- gentel Mario. We wiped arouind the vertex cambers north side on the floor and east arm racks.

 

  11373   Wed Jun 24 08:05:43 2015 SteveUpdatePSLlaser turned on

The laser went off around 11am yesterday. It was turned on

  11374   Wed Jun 24 17:30:45 2015 ericqUpdateLSCDFD Delay length

This afternoon, I had a fruitful conversation with Rich Abbott about various kinds of cables.

I've sent an email to Steve to ask him to buy 2 x 50m LMR-195 cables, with male SMA connectors. Rich highly recommends these for their polyethylene insulation, which makes them less microphonic and less susceptible to thermal expansion, low loss, and multi-ply bonded foil shielding.

50m means that the peak to peak mixer output swing corresponds to about a MHz. 1nV of mixer output noise looks like ~6mHz frequency noise, for a Level 3 mixer appropriately driven. As a comparison, the lowest our in-loop green PDH error signals get is 0.1Hz/rtHz. 

The cable attenuation should be around 4.2dB at 50MHz, and 7.3dB at 150MHz, according to the data sheet. Thus, we should not be in the regieme where we are losing sensitivity to the attenuation. 

By my rough geometric estimation, these two should fit in the 2U box I got ahold of today fine. Jessica is designing the front panel. 

We currently have ~30m of RG-408 and RG-142 as our delay lines. 

  11375   Thu Jun 25 12:03:42 2015 Max IsiUpdateGeneralSummary page status

The summary pages have been down due to incompatibilities with a software update and problems with the LDAS cluster. I'm working at the moment to fix the former and the LDAS admins are looking into the latter. Overall, we can expect the pages will be fully functional again by Monday.

  11376   Thu Jun 25 14:18:46 2015 Max IsiUpdateGeneralSummary page status

The pages are live again. Please allow some time for the system to catch up and process missed days. If there are any further issues, please let me know.
URL reminder: https://nodus.ligo.caltech.edu:30889/detcharsummary/

Quote:

The summary pages have been down due to incompatibilities with a software update and problems with the LDAS cluster. I'm working at the moment to fix the former and the LDAS admins are looking into the latter. Overall, we can expect the pages will be fully functional again by Monday.

 

  11377   Thu Jun 25 15:07:50 2015 SteveUpdatesafetySurfs Safety 2015

Jessica Pena, Megan Kelly, Eve Chase and Ignacio Magana received 40m specific basic safety traning today.

  11378   Thu Jun 25 18:20:15 2015 ericqUpdateLSCALS reconstruction in progress

I've been working on getting a working ALS up and running. Things are in a bit of a transient state right now; I'm off to softball and dinner, and will resume work tonight. There will be a more detailed ELOG then, but here are some quick notes:

  • c1als has been gutted, phase trackers are working successfully in c1lsc frontend. All channel names remain the same. 
  • BEATX is on the ADC channels where AS165 used to live, BEATY at POP55. 
  • Used a marconi to drive the aLIGO LSC demod board in the LSC rack, was able to lock digital phase tracker on two channels
  • Noise looks pretty cruddy. Lots of 60Hz harmonics on both channels, maybe from marconi drive? Pickup in the delay line?
  • BEATX whitening filter maybe has something fishy going on; excess noise at 2kHz
  • Unclear if BEATY whitening filter is actually doing anything. 
  • Whitening gain switching works fine for both, though. Haven't revisited the switching code, so its controlled in the old RFPD place for now.
  • Whitening triggering is not set up, will require some thought and model work that isn't neccesary yet. 
  • Agilent analyzer, marconi, and old delay lines are currently stashed behind the LSC rack; I will resume work with them tonight. 

The main thing left to do is to install the RF amplifiers at the PSL table and route the green beat signals over to the LSC rack. I fear that some investigation into the whitening filters will be neccesary to make the performance adequate, however. 

  11379   Fri Jun 26 03:24:18 2015 ericqUpdateLSCALS reconstruction in progress

Too sleepy to make full ELOG. Stay tuned. 

Two 25dB amplifiers (with fins!) are living in the top shelf on the PSL table, inputs currently grounded. I broke out the fused 24V power from the AOM driver to power the two amps and the AOM driver. I used the POP55 and AS165 heliax cables to get their outputs to the LSC rack, through delay lines, into demod board. 

Driving with -20dBm at 55MHz, the BEATX signal chain has about 60Hz RMS noise, which is about what I measured for driving the old beatbox with a marconi. High frequency noise is a much nicer shape, though. The BEATY signal didn't seem to be getting through, will double check soon. 

Still old delay cables, not nicely shielded or isolated or anything. We'll have to pipe the monitor signal from the LSC rack over to the control room analyzer now. 

 

  11380   Fri Jun 26 23:18:52 2015 Eve ChaseUpdateCDSSummary Page Updates

Motivation:

My SURF project largely focuses on updating and improving the 40m summary pages. I began to explore and experiment with the already existing summary page code to better understand the required code and eventually lead to tangible improvements of the summary pages.

 

What I did:

I practiced moving from one tab of the summary pages to another. Specifically, I copied the ETM Optical Levers plot from SUS: OpLev to Sandbox, without removing it from its original location. Additionally, I created my own tab to further test the summary pages, titled “Eve”.

KA ed: The configuration files are located at /cvs/cds/caltech/chans/GWsummaries. It is under svn control.

Result:

All changed appeared on the summary pages without much hassle and without any errors.

  11381   Mon Jun 29 12:28:45 2015 ericqUpdateLSCALS reconstruction in progress

Turns out the reason that the BEATY signal wasn't working is that one of the two RF amplifiers (both of which are model ZHL-32A), isn't amplifying. Voltage at the pins is fine, so maybe its just broken. When the ZHL-3As that Rana ordered arrive, I'll install those. 

Switching the working amplifier between the two channels, and using a Marconi driving -20dBm (the Y green beatnote amplitude), the phase tracker output RMSs are 70Hz and 150Hz for X and Y, respectively, which isn't too exciting. There is enough whitening gain and filtering that I don't think ADC noise is an issue (The magnitude of the phase tracker Q is ~10kcounts after +6dB whitening gain). 

The RMS in both channels mostly comes from a whole mess of 60Hz harmonics. I'll see what I can do by taking better care of the delay line cables, but it is kind of weird that this would be worse now, given that there was little care given to them before either.

Also, for now, so I don't have to lug the marconi around everywhere, I'm currently driving both channels of the demod board with a spare 55MHz LO output of the LSC LO distribution box, which ends up being a factor of 5 smaller phase tracker error signal, but the noise level is about the same as with the marconi. 

  11382   Mon Jun 29 17:40:56 2015 Max IsiUpdateGeneralSummary pages "Code status" page fixed

It was brought to my attention that the "Code status" page (https://nodus.ligo.caltech.edu:30889/detcharsummary/status.html) had been stuck showing "Unknown status" for a while.
This was due to a sync error with LDAS and has now been fixed. Let me know if the issue returns.

  11383   Tue Jun 30 05:47:38 2015 ranaUpdateLSCUse BALUNs
Quote:

The RMS in both channels mostly comes from a whole mess of 60Hz harmonics. I'll see what I can do by taking better care of the delay line cables, but it is kind of weird that this would be worse now, given that there was little care given to them before either.

BALUNs

  11385   Tue Jun 30 20:26:24 2015 Eve UpdateGeneralMinor Summary Page Changes

I made several small, nit-picky changes to the summary pages.

 

Motivation:

I'm still working on getting used to editing the summary pages. I also wanted to change some of the easy-to-alter cosmetics of the pages.

 

What I did:

I changed axis ranges, axis labels, and typos throughout the summary pages. Read below for an excrutiating list of the minor details of my alterations, if you wish:

  • Changed axes on LSC control signals plots on the Summary tab (but will probably change these back to their original state)
  • Moved an OpLev plot from the Sandbox tab to "Eve" tab
  • Increased the y axis range on IOO MC2 Trans QPD and IMC REFLY RFPD DC plots (which may change when I better incorporate triggers into these plots)
  • Fixed title on IOO Whitened Spectrogram and Rayleigh Spectrogram
  • Fixed degree sign on Weather: Temperature and PSL Table Temperature
  • Fixed percent sign on Weather: Humidity
  •  

Results:

So far, everything looks good. I'll continue to make more changes later this week and hope to soon get on to more substatial changes.

  11386   Wed Jul 1 09:33:31 2015 KojiUpdateGeneralShutters closed, watch dogs disabled for the RCG upgrade

I closed the PSL/GREEN shutters and shut off the LSC feedback/SUS watch dogs at 9AM PDT, to allow Jamie to start his disruptive work.
 

  11387   Wed Jul 1 10:01:25 2015 SteveUpdateVACRGA scan pd78 day 275

 

 

  11388   Wed Jul 1 11:45:48 2015 SteveUpdatePEMcleaning around ETMX chamber
Quote:

Keven is our regular janitor is out for a few weeks.

The sub is careful- gentel Mario. We wiped arouind the vertex cambers north side on the floor and east arm racks.

 

Mario wiped the floor around the ETMX chamber today.

  11389   Wed Jul 1 16:16:46 2015 IgnacioUpdateGeneralAccelerometers reinstalled for future huddle test

Today, I installed the Wilcoxon accelerometers in the table near the end of the mode cleaner. I only set three of them up instead of all six. They were set up just as Rana suggeted we should have them properly set up, i.e. cables being tighten up, and a box on top to prevent any airflow introducing any disturbances. We are planning on running the huddle test on these guys once the upgrade? to the interferometer is done.

The cables were tightly clamped to the table as shown below, I used a thick piece of shock absorbing rubber to do this.

 A small piece of thin rubber was used to hold each of the accelerometers tightly to the table in order not to damage them.

We had to borrow Megan's and Kate's piece of black foam in order to seal one of the sides properly, as the cable had to come out through somewhere. We didn't want to mess with drilling any holes into the box! 

There was a small crack even after using the foam. I sealed it up with duck tape.

The box isn't perfect, so there were multiple cracks along the bottom and top of it that could potentially allow for air to flow to the inside. Eric suggested that we should be super careful this time and do it right, so every crack was sealed up with ducktape.

 

Finally, we needed something heavy to be placed on top of the box to hold everything well. We used Rana's baby to accomplish this goal.

Just kidding! Rana's baby is too delicate for our purposes. A layman box of heavy cables was used instead. 

 

  11391   Sun Jul 5 18:14:13 2015 IgnacioUpdatePEMWilcoxon Accelerometer Huddle Test

Updated: On Thursday/Friday (sorry for late elog) I was messing with Eric's Wilcoxon 731A accelerometer huddle test data that was taken without the box and cables being adjusted properly. Anyways, I performed the three cornered hat analysis as he had done but I also performed a six cornered hat method as well instead of permuting around in pairs of three accelerometers. The following plots of the ASD's show the results,

It is interesting to note the improvement at low frequencies when six accelerometers are used instead of six while at higher frequencies we can clearly see how the results are worst than the three hat results.

I decided to take a mean of all six accelerometers measured ground signal as well as that for their computed selfnoises, this is plotted below,

 

Notice the obvious improvement along the entire frequency band of the measurements when all accelerometers are used in the data analysis.

I also performed some Wiener filtering of this data. There was an obvious improvement in the results,

The mean of the signals is also plotted below, just as I did with the cornered hat methods,

 

I also compared the mean self noise of the accelerometers against the manufacturers calculated selfnoise that Rana put up on Github. Both methods are compared against what the manufacturer claims,

As expected the measured noise curves of the Wilcoxon is not as good as what the manufactures stated. This should improve once we redo the huddle test with a better experimental setup. We have some pretty interesting results with the six cornered hat method at around 5 Hz, it is surprisingly accurate given how rough the calculations seemed to be.

I have attached my code for reference: code_accel.zipselfnoise_allsix.png

SEE attachments for better plots of the six accelerometers...

  11394   Tue Jul 7 23:26:19 2015 KojiUpdateCDSAttempt to list CDS issues

As Jamie succeded to realize somewhat workable condition of the 40m CDS, I tried to list the obvious CDS issues so that we can attack them one by one.

  1. c1cal is constantly time-outing now (t>60usec). c1sus is close to it (t=56~57us)
  2. We should check the trends of the CPU meters ("C1:FEC-**_CPU_METER"). In fact this should be listed in the summary pages in a new CDS tab.
  3. Probably this is related to 1): c1lsc is constantly showing IPC error (bit0 = shmem). C1LSC_IPC_STATUS.adl is telling that this is coming from the IPC error between c1lsc and c1cal. ("C1:CAL-LSC_SENSMAT_OSC_****"). This information is found by opning C1LSC_GDS_TP.adl screen and click RT NET STAT button next to the IPC error status.
  4. We wonder how the RFM access is accelerated or decelerated by this upgrade.
  5. We need tests to see if the time delays of the models/IPCs are still reasonable.
  6. LSC Overviw screen has a small digest of the CDS status. Now there are many white boxes that correspond to the channels "C1:FEC-**_DIAG1".
  7. All realtime systems have default (0 or 1) epics channel values (i.e. gains, FM switches, matrices, etc). Need burtrestores.
  8. I tried to burtrestore the models but burtgooey indicated there are some errors.
  9. Detailed check of the snapshot files comparing snapshot files in /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2015/Jul/7/19:07 and /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2015/Jun/1/19:07 :
    • c1alsepics shows bunch of volatile channels to be snapshot. It seems that all of the static epics channels are missing in the snapshot file. Is this related to the current omission of the slow data acquisition? => No actually this must be the modification of the ALS model to accommodate the ALS in the LSC model for the new ALS setup.
    • c1lscepics was checked indeed slow channels were properly snapshot. So what was the problem in burting???
    • I made a simple csh script to restore the snapshots one by one while collecting the error messages.
      This script is located as /users/koji/150707/burtrevert.sh
    • #!/bin/csh
      echo 'This script restores all of the snapshot files found in' $argv[1] '.'
      echo 'Are you sure? y/n'

      set ans = $<

      set ANS = `echo $ans | tr "[:upper:]" "[:lower:]" `
      if ($ANS == y) then
          foreach fname ($argv[1]/*epics.snap)
          echo ''
          echo '#################################'
          echo $fname
          echo '#################################'

              burtwb -f $fname
          end
      else
          echo "exiting..."
      endif
       
    •  Now I ran the command
      ./burtrevert.sh /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2015/Jun/1/19:07 &>burt.log
      This lists up the missing channels. The zipped log is attached to this entry.
    • Burting old snapshot always crashes the RT process "c1sus" (not the c1sus host). If I use the newly generated snapshot today,
      the process does not crash. The process halts at the cycle time of 74us (>60us). I left the process crashed so that we can take a new snapshot with the matrix numbers filled. Once we have the correct snapshot, we don't need to worry about this crash. Let's see.
    • c1sus still crashes with the new burt file. Theremust be a trigeer that makes the model frozen. We need to split the burtfile into pieces
      to figure out which line causes the halt.
  11401   Fri Jul 10 17:57:38 2015 Max IsiUpdateGeneralSummary pages down

The summary pages are currently unstable due to priority issues on the cluster*. The plots had been empty ever since the CDS updated started anyway. This issue will (presubmably) disappear once the jobs are moved to the new 40m shared LDAS account by the end of next week.

*namely, the jobs are put on hold (rather, status "idle") because we have low priority in the processing queue, making the usual 30min latency impossible.

  11403   Mon Jul 13 14:08:10 2015 ericqUpdateElectronicsNew RF amps, housed

I made a little box for the new RF amplifiers we'll be using for the green beatnotes, to keep things tidy on the PSL table. They are both Minicircuits model ZHL-3A-S.

I took TFs of their response with the agilient analyzer (calibrating out the cables, splitters, etc.) Powered at +24V, we get a solid ~27dB of gain up to around 200MHz, which is fine for our needs. The phase profile is mostly a 6-7 nsec delay, which is negligible for ALS. Data files are attached. 

Koji looked at me like I was crazy for using a BNC connector for the DC power. I haven't yet been able to find panel mount banana connectors, but when I do, I'll replace it. 


Banana'd:

  11407   Tue Jul 14 10:23:27 2015 IgnacioUpdateGeneralOptimal detector array placement thoughts

Over the past few days, I've been thinking about how to workout the details conerning Rana's request about a 'map' of the vicinity of the 40m interferometer. This map will take the positions of N randomly placed seismic sensors as well as the signals measured by each one of them and the calculated cross correlations between the sensors and between the sensors and the test mass of interest to give out a displacement vector with new sensor positions that are close to optimum for better seismic (and Newtonian) noise cancellation.

Now, I believe that much of the mathematical details have been already work out by Jenne in her thesis. She explains that the quantity of interest that we wish to minimize in order to find an optimal array is the following,

R = \sqrt{1-\frac{\vec{C}_{SN}^T C_{SS}^{-1}\vec{C}_{SN} }{C_{NN}}}

where  \vec{C}_{SN} is the cross-correlation vector between the seismic detectors and the seismic (or Newtonian) noise, C_{SS} is the cross-correlation matrix between the sensors and C_{NN} is the seismic (or Newtonian) noise variance. 

I looked at the paper that Jenne cited from which she obtained the above quantity and noted that it is a bit different as it contains an extra term inside the square root, it is given by

R' = \sqrt{1-\frac{\vec{C}_{SN}^T (C_{SS}^{-1}+C_{\Sigma\Sigma})\vec{C}_{SN} }{C_{NN}}}

where the new term, C_{\Sigma\Sigma} is the matrix describing the self noise of the sensors. I think Jenne set this term to zero since we can always perform a huddle test on our detectors and know the self noise, thus effectively subtracting it from the signals of interest that we use to calculate the other cross correlation quantities.

Anyways, the quantity R above is a function of the positions of the sensors. In order to apply it to our situation, I'm planning on:

     1) Performing the huddle tests on our sensors, redoing it for the accelerometers and then the seismometers (once the data aquisition system is working... )  

     2) Randomly (well not randomly, there are some assumptions we can make as to what might work best in terms of sensor placement) place the sensors around the interferometer. I'm planning on using all six Wilcoxon 731A accelerometers, the two Guralps and the STS seismometer (any more?).

     3) Measure the ground signals and use wiener filtering in order to cancel out their self noises.

     4) From the measured signals and their present positions we should be able to figure out where to move the sensors in order to optimize subtraction.

i have also been messing around with Jenne's code on seismic field simulations with the hopes of simulating a version of the seismic field around the 40m in order to understand the NN of the site a little better... maybe. While the data aquisition gets back to a working state, I'm planning on using my simulated NN curve as a way to play around with sensor optimization before its done experimentally.

i have as well been thinking and learning a little bit about source characterization through machine learning methods, specially using neural networks as Masha did back in her SURF project on 2012. I have also been looking at Support vector machines. The reasons why I have been looking at machine learning algorithms is because of the nature of the everchanging seismic field around the interferometer. Suppose we find a pretty good sensor array that we like. How do we make sure that this array is any good at some time t after it has been found? If the array mostly deals with the usual seismic background (quiet) of the site of interest, we could incorporate machine learning techniques in order to mitigate any of the more random disturbances that happen around the sites, like delivery trucks, earthquakes, etc.

  11410   Tue Jul 14 13:55:28 2015 jamieUpdateCDSrunning test on daqd, please leave undisturbed

I'm running a test with daqd right now, so please do not disturb for the moment.

I'm temporarily writing frames into a tempfs, which is a filesystem that exists purely in memory.  There should be ZERO IO contention for this filesystem, so if the daqd failures are due to IO then all problems should disappear.  If they don't, then we're dealing with some other problem.

There will be no data saved during this period.

  11411   Tue Jul 14 16:47:18 2015 EveUpdateSummary PagesSummary page updates continue during upgrade

I've continued to make changes to the summary pages on my own environment, which I plan on implementing on the main summary pages when they are back online.

 

Motivation:

I created my own summary page environment and manipulated data from June 30 to make additional plots and change already existing plots. The main summary pages (https://nodus.ligo.caltech.edu:30889/detcharsummary/ or https://ldas-jobs.ligo.caltech.edu/~max.isi/summary/) are currently down due to the CDS upgrade, so my own summary page environment acts as a temporary playground to continue working on my SURF project. My summary pages can be found here (https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/20150630/); they contian identical plots to the main summary pages, except for the Summary tab. I'm open to suggestions, so I can make the summary pages as useful as possible.

 

What I did:

  • SUS OpLev: For every already existing optical lever timeseries, I created a corresponding spectrum, showing all channels present in the original timeseries. The spectra are now placed to the right of their corresponding timeseries. I'm still playing with the axes to make sure I set the best ranges.
  • SUSdrift: I added two new timeseries, DRMI SUS Pitch and DRMI SUS Yaw, to add to the four already-existing timeseries in this tab. These plots represent channels not previously displayed on the summary pages
  • Minor changes
    • Added axis labels on IOO plot 6
    • Changes axis ranges of IOO: MC2 Trans QPD and IOO: IMC REFL RFPD DC
    • Changes axis label on PSL plot 6

 

Results:

So far, all of these changes have been properly implemented into my personal summary page environment. I would like some feedback as to how I can improve the summary pages.

 

 

  11413   Tue Jul 14 17:06:00 2015 jamieUpdateCDSrunning test on daqd, please leave undisturbed

I have reverted daqd to the previous configuration, so that it's writing frames to disk.  It's still showing instability.

  11416   Wed Jul 15 17:05:06 2015 JessicaUpdateGeneralBandpass Pre-Filter created

I applied a bandpass filter to the accelerometer huddle data as a pre-filter. The passband was from 5 Hz to 20 Hz. I found that applying this pre-filter did very little when comparing the PSD after pre-filtering to the PSD with no pre-filtering. There was some improvement though, just not a significant amount. For some reason, it also seemed as though the second accelerometer improved the most from pre-filtering the data, while the first and third remained closer to the unfiltered noise. Also, I have not yet figured out a consistent method for choosing passband ripple and stopband attentuation, both of which determine how good the filter is. 

My next step in pre-filtering will be determining a good method for choosing passband ripple and stopband attenuation, along with implementing other pre-filtering methods to combine with the bandpass filter. 

  11418   Thu Jul 16 01:04:21 2015 ericqUpdateGeneralStarting IFO recovery, DAC troubles

I've been trying to start recovering IFO functionality, but quickly hit a frustrating roadblock. 

Upon opening the PSL shutter, and deactivating the MC mirror watchdogs, I saw the MC reflected beam moving way more than normal. 

A series of investigations revealed no signals coming out of c1sus's DAC.  crying

The IOP (c1x02) shows two of its DAC-related statewords (DAC and DK) in a fault mode, which means (quoting T1100625):

"As of RCG V2.7, if an error is detected in oneor more DAC modules, the IOP will continue to run but only write zero values to the DAC modules as a protective measure. This can only be cleared by restarting the IOP and all applications running on the affected computer."

The offending card may be DAC1, which has its fourth bit red even with only the IOP running, which corresponds to a "FIFO error". /proc/c1x02/status states, in part:

DAC #0 16-bit fifo_status=2 (OK)
DAC #1 16-bit fifo_status=3 (empty)
DAC #2 16-bit fifo_status=2 (OK)

Squishing cables and restarting the frontend have not helped anything. 

c1lsc, c1isce[x/y] are not suffering from this problem, and appear to be happily using their DACs. c1ioo does not use any DAC channels. 


As a further headache, any time I restart any of the models on the c1sus frontend, the BURT restore is totally bunk. Moreover, using burtgooey to restore a good snapshot to the c1sus model triggers a timing overflow and model crash, maybe not so surprising since the model seems to be averaging ~56usec or so. 

  11419   Thu Jul 16 03:01:57 2015 ericqUpdateLSCOld beatbox hooked back up

I was having issues trying to get reasonable noise performance out of the aLIGO demod board as an ALS DFD. Terminating the inputs to the LSC whitening inputs did not show much 60Hz noise, and an RMS in the single Hz range. 

A 60Hz line of hundreds of uV was visible in the power spectrum of the single ended BNC and double-ended DB25 outputs of the board no matter how I drove or terminated.

So, I tried out hooking up the ALS beatbox. It turns out to work better for the time being; not only is the 60Hz line in the analog outputs about ten times smaller, the broadband noise floor in the resultant beat spectrum when driven by a 55MHz LO on the LSC rack is a fair bit lower too. I wonder if this is due to not driving the aLIGO board LO at the +10dBm it expects. With the amplifiers and beat note amplitudes we have, we'd only be able to supply around 0 dBm anyways. 

Here's a comparison of the aLIGO board (black) and ALS beatbox (dark green) driven with the 55MHz LO, both going through the LSC whitening filters for a resultant magnitude of 3kCounts in the I-Q plane. The RMS sensing noise is about 30 times lower for the beatbox. (Note, this is with the old delay cables. When we switch to the 50m cables, we'll win further frequency noise sensitivity through the better degrees->Hz calibration.) I'm very interested to see what the green beat spectrum looks like with this setup. 

Not only is the 60Hz line smaller, there is simply less junk in the beatbox signal. I did not expect this to be the case. 

There were some indications of funky status of the aLIGO board: channels 3 and 4 are totally nonfunctioning, so who knows what's going on in there. I've pulled it out, to take a gander if I can figure out how to make it suitiable for our purposes. 

  11420   Thu Jul 16 11:18:37 2015 jamieUpdateGeneralStarting IFO recovery, DAC troubles
Quote:

I've been trying to start recovering IFO functionality, but quickly hit a frustrating roadblock. 

Upon opening the PSL shutter, and deactivating the MC mirror watchdogs, I saw the MC reflected beam moving way more than normal. 

A series of investigations revealed no signals coming out of c1sus's DAC.  crying

The IOP (c1x02) shows two of its DAC-related statewords (DAC and DK) in a fault mode, which means (quoting T1100625):

"As of RCG V2.7, if an error is detected in oneor more DAC modules, the IOP will continue to run but only write zero values to the DAC modules as a protective measure. This can only be cleared by restarting the IOP and all applications running on the affected computer."

The offending card may be DAC1, which has its fourth bit red even with only the IOP running, which corresponds to a "FIFO error". /proc/c1x02/status states, in part:

DAC #0 16-bit fifo_status=2 (OK)
DAC #1 16-bit fifo_status=3 (empty)
DAC #2 16-bit fifo_status=2 (OK)

Squishing cables and restarting the frontend have not helped anything. 

c1lsc, c1isce[x/y] are not suffering from this problem, and appear to be happily using their DACs. c1ioo does not use any DAC channels. 

We need to update the indicators on the CDS_FE_STATUS screen to expose the new indicators, so that we have better visibility for these issues.

I'm not sure why this DAC is failing. It may indicate an actual problem with the DAC itself.

Quote:

As a further headache, any time I restart any of the models on the c1sus frontend, the BURT restore is totally bunk. Moreover, using burtgooey to restore a good snapshot to the c1sus model triggers a timing overflow and model crash, maybe not so surprising since the model seems to be averaging ~56usec or so. 

This is related to changes to how the front ends load their safe.snaps. I think they're now explictly expecting the file:

targtet/<model>/<model>epics/burt/safe.snap

I'll come over this afternoon and we can get acquainted with the new SDF system that now handles management of the safe.snap files.

  11421   Thu Jul 16 16:33:56 2015 JessicaUpdateGeneralAdded Bode Plots of Bandpass Filter

I updated the bandpass filter I was using, finding that having different stopband attenuations before and after the passband better emphasized the area from 3 Hz to 20 Hz. I chose a low passband ripple but high stopband attenuation to do this. My passband ripple was 2 dB, the first stopband was 25 dB, and the second stopband attenuation was 40 dB. As can be seen in the filter Magnitude plot, this resulted in a fairly smooth passband and a fairly step dropoff to the stopband, which will better emphasize the region I am trying to isolate. My goal was to emphasize the 3-20 Hz region 10-30 times more than the outside regions. I think I accomplished this by looking at the Bode plot, but I may have chosen the second stopband attenuation to be slightly too high for this. 

ELOG V3.1.3-