Someone installed "Debian" on allegra. Why? Dataviewer doesn't work on there. Is there some advantage to making this thing have a different OS than the others? Any objections to going back to Ubuntu12?

I suggest:

1. Disable the path which goes to the two spare outputs. Replace the ERA-5 with a 50 Ohm resistor to terminate that path. Make sure the ERA bias voltage is not shorting into something.
2. Remove the ERA amps from the ASC path and remove the switch. Make it fixed gain such that we get +27 dBm out of the front.
3. Put the ASC output into the 1U multi-splitter box and attenuate those outputs so that they supply ~0 dBm to the 2 WFS and the LSC Demod board.

I think this then allows us to have the low noise OCXO signals everywhere with enough oomph.

I don't know if anyone looked at the time series (not trend) or spectrum of the Microphone after installation, but it looks bad and featureless to me. Is the Microphone broken?

This shows the spectrum from early this morning and again from tonight. You can see that it is bi-stable in its noise properties. This thing is busted; we're now removing it from the PSL so that it doesn' light it self on fire.

and the song remains the same...

the version of SVN on these workstations is ahead of the one on the other workstations so now we can't do 'svn up' on any of the Ubuntu12 machines. One allegra and optimus I get this error:

controls@allegra|GWsummaries> svn up
Updating '.':
svn: E180001: Unable to connect to a repository at URL 'file:///cvs/cds/caltech/svn/trunk/GWsummaries'
svn: E180001: Unable to open an ra_local session to URL
svn: E180001: Unable to open repository 'file:///cvs/cds/caltech/svn/trunk/GWsummaries'

I'm not sure if its possible to downgrade our chans repo back to the old one, but I highly recommend that no one do 'svn upgrade' in any of our repos until we remove all of the Debian installs in the 40m lab or hire a full-time sysadmin.

Re-aligned the beam going into the PMC today around 5 PM. I noticed that its all in pitch and since I moved both of the mirrors by the same amount it is essentially a vertical translation.

I wonder if the PMC is just moving up and down due to thermal expansion in the mount? How else would we get a pure vertical translation? Need to remember next time if the beam goes up or down, and by how many knob turns, and see how it correlates to the lab temperature.

In working on automatic DARM loop design, we have this code:

https://git.ligo.org/rana-adhikari/ModernControls/tree/master/OptimalFeedback/GlobalCost

the things in there like mkCost*, etc. have examples of the cost functions that are used. It may be useful to look at those and then make a similar cost function calculation for the MCL/MCF loop.

True - its an issue. Koji and I are updating zita into Ubuntu16 LTS. If it looks like its OK with various tools we'll swap over the others into it. Until then I figure we're best off turning allegra back into Ubuntu12 to avoid a repeat of this kind of conflict. Once the workstations in the LLO control room are running smoothly on a new OS for a year, we can transfer into that. I don't think any of us wants to be the CDS beta tester for DV or DTT.

c1iool0 was down again. Rather than key the crate, this time I just pushed the reset button on the front and it came back.

As move towards the wonderfulness of AcroMag, we also have to buy a computer  to handle all of these IOCs. Let's install the new c1iool0 over by the SUS computer.

To remind myself about how to put filter caps on the mini-circuits RF Amps, I looked at Koji's recent elog. Its mostly about op-amps, but the idea holds for us.

We want a big (~100 uF) electrolytic with a 50V rating for the +24V RF Amp. And then a 50V ceramic capacitor of ~0.1 uF close to the pins. Remember that the power feed through on the Mini-circuits case is itsself a capacitive feedthrough (although I guess its a ~100 pF).

Later, we should install in this box an active EMI filter (e.g. Vicor)

I would think that we want to fix the I/Q orthog inside the demod board by trimming the splitter. Mixing the Q phase signal to the I would otherwise allow coupling of low frequency Q phase junk from HOMs into the MC lock point.

Question for Craig: What does the SNR of our lines have to be? IF we're only trying to calibrate the actuator in the audio band over long time scales, it seems we could get by with more frequency noise. Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?

Yikes. Please change the all teh WFS DQ channels sample rates from 2048 down to 512 Hz. I doubt we ever need anything about 180 Hz.

There is sometimes an issue with this: if our digital AA filters are not strong enough, the noise about above 256 Hz can alias into the 0-256 Hz band. We ought to check this quantitatively and make some elog statement about our AA filters. This issue is also seen in DTT when requesting a low frequency spectrum: DTT uses FIR filters which are sometimes not sharp enough to prevent this issue.

OK, but the questions still stands: "Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?"

The fringes seen on the oscope are mostly likely due to the interference from multiple light beams. If there are laser beams hitting mirrors which are moving, the resultant interference signal could be modulated at several Hertz, if, for example, one of the mirrors had its local damping disabled.

Huh? So should we ask them to put the container back? Or do you have some other theory about ETMX tripping that is not garbage related?

The input offset on the MC length servo board changes the lock point of the length loop (by how much? need to calibrate this slider into meters & Hz).

The SUM signal on the MC WFS is ~few 1000. This is several times larger than the pit/yaw signals. This is bad. it means that the TEM00 mode on the WFS (or what the WFS interperets as a TEM00) is larger than the TEM01/10 that its supposed to measure.

So if the beam moves on the WFS head it will convert this large common mode signal into a differential one.

We moved the MC Servo offset around from -3 to +3 V today and saw that it does affect the transmitted light level, but we need to think more to see how to put the offset at the real center of the resonance. This is complicated by the fact that the MCWFS loops seem to have some several minutes time constant so things are essentially always drifting.

1. Characterize and juice up the WFS loops.
2. Figure out how to set the MC length loop offset. Is this bad offset changing the zero point of the MC WFS loops?
3. If so, it may be a source of excess jitter noise in the interferometer.

I changed the McREFL SMOO to make it easier to use this noisy channel to diagnose small alignment changes:

caput C1:IOO-MC_RFPD_DCMON.SMOO 0.1

This measurement looks bogus - the difference between dark and not dark is not significant enough to believe. Need to figure out how to match better into the ADC range.

The MC was sort of misaligned. It was locking on some vertical HOMs. So I locked it and aligned the suspensions to the input beam (not great; we should really align the input beam to the centered spots on the MC mirrors).

With the HOMs reduced I looked at the MC servo board gains which Guatam has been fiddling with. It seems that since the Mod Depth change we're getting a lot more HOM locks. You can recognize this by seeing the longish stretches on the strip tool where FSS-FAST is going rail-to-rail at 0.03 Hz for many minutes. This is where the MC is locked on a HOM, but the autolocker still thinks its unlocked and so is driving the MC2 position at 0.03 Hz to find the TEM00 mode.

I lowered the input gain and the VCO gain in the mcdown script and now it very rarely locks on a HOM. The UGF in this state is ~3-4 kHz (I estimate), so its just enough to lock, but no more. I tested it by intentionally unlocking ~15 times. It seems robust. It still ramps up to a UGF of ~150 kHz as always. 'mcdown' commited to SVN.

For sensing matrix, better to use single frequency sine response. We don't want to measure around the bounce or above the 28 Hz cutoff filters in the MC SUS.

What readouts do we have for the PMC length? If we could have a calibrated & whitened error and control signal for the PMC up to 16 kHz, perhaps we could see at what frequencies we can use it as a faux-RefCav.

Going to the summary pages and looking at 'Today' seems to break it and crash the browser. Other tabs are OK, but 'summary' is our default page.

I've noticed this happening for a couple of days now. Today, I moved the .ini files which define the config for the pages from the old chans/ location into the /users/public_html/detcharsummary/ConfigFiles/ dir. Somehow, we should be maintaining version control of detcharsummary, but I think right now its loose and free.

Debian doesn't like EPICS. Or our XY plots of beam spots...Sad!

Very, very cool!  

What you have drawn looks good to me: the cut should be between TP3 and pin3 of the AD620. This should maintain the DC coupled respons for the single-pin LEMO and backplane EPICS monitors.

We want to use the PMC signal down to low frequencies, so the filter on the input of the AD620 should have a low frequency cutoff, but we should take care not to spoil the noise of the AD620 with a high impedance resistor.

It has a noise of 100 nV/rHz and 1 pA/rHz at 1 Hz. If you use 47 uF and 10 kOhm, you'll get fc = 1/2/pi/R/C ~ 0.3 Hz so that would be OK. 

I just did remote apt-get update, apt-get upgrade, and then reboot on nodus. ELOG started up by itself.

good cal. I wonder if this data also gives us a good measurement of the cavity pole or if the photo-thermal self-locking effect ruins it. You should look at the data for the positive sweeps and negative sweeps and see if they give the same answer for the cavity poles. Also, maybe we can estimate the PMC cavity pole using the sidebands as well as the carrier and see if they give the same answer? 

I'm suspicious of this temperature sensor comparison. Usually, what they mean by accuracy is not the same as what we mean. I would not buy these yet. How about we just use what Caryn used several years ago (elog search) ?

  PS  Steve LM34             

AIC Wiki updated to latest stable version of DokuWiki: 2017-02-19b "Frusterick Manners" + CAPTCHA + Upgrade + Gallery PlugIns

Our minute trends are still not available through NDS2 from the outside world due to the bad config of the DAQ, but I can confirm that we still have the minute-raw capability. This is 111 days of Seismic BLRMS.

However, it seems we're only able to get ~1 week of lookback on our second trends and that is low-down dirty shame. We used to have over a month of second trend lookback before the last decade of 'upgrades'.

we installed a new curved 34" doublewide monitor on Rossa, but it seems like it has a defective dead pixel region in it. Unless it heals itself by morning, we should return it to Amazon. Please don't throw out he packing materials.

Steve 8am next morning: it is still bad The monitor is cracked. It got kicked while traveling. It's box is damaged the same place.

Shipped back 4-17-2017

What's the reasoning behind setting the the gain to this new value? i.e. why do these 'margins' determine what the gain should be?

one of these signals does not look like the others: explanation?

We ought to put the camera software on the shared disk; I don't think there's any speed reasons that it needs to be local.

Its OK to use optimus as the camera server for testing at the moment, but once we have things running, we'll install a few more cameras. With ~4-5 GigE running, we may not want to share with optimus, since we're also using it for comsol and skymap calculations.

That's a new failure mode. Probably we can't trust the power to be safe anymore.

Need Steve to order a couple of surge suppressing power strips for the monitors. The computers are already on the UPS, so they don't need it.

I think the most important next two items to budget are the optical lever noise, and the coil driver noise. The coil driver noise is dominated at the moment by the DAC noise since we're operating with the dewhitening filters turned off.

I tried to get some minute trend data today, but was unable to get it from inside or outside the control room using our matlab or python tools.

It seems the NDS2 interface will not work anywhere since it needs our minute trends to be written as frames; in the last version that Jamie left us, our minute trend frame files are not being written since they lead to periodic daqd crashes.

From inside the control room, we can get the minute trend (only with DataViewer). I've attached 30 days of BS_X just to show its real.

We can get the numerical data from the Grace plot window using the menu option Data->Export->ASCII.

You must select all of the 'Write Sets' to get all of the traces in the plot window. The resulting ascii file is not in a great format, but its not terrible.

That's a good find.

1. The OL control signal can be gotten from the DQ error signal. You just need to multiply it by the digital filters and the gain. The state of the filters and the gain can be gotten using matlab tools like getFotonFilt.m. For python ChrisW wrote a tool called foton.py which is in the GDS SVN. You should ask him for it. It requires access to some ROOT libraries to run.
2. We should have sub budgets for everything like OL and thermal, etc. They should be automatically produced each time you run the main budget and should be separate pages in the same PDF file. Jamie / Chris may have something going along these lines so check to see if they are already on it.

I rebooted megatron around 12:20 today. It had dozens of stalled medm process (some of them there since February!). I couldn't kill them without them coming back like zombies, so I did sudo reboot.

I believe the ETMs and ITMs are different from the others.

I did an 'svn update' in userapps/cds/ which pulled in some changes from the sites as well as various CDS utilities in common/ and utilities/

This was to get Keith Thorne's get_data.m and get_data2.m scripts which I tested and they seem to be able to get data. No success with getting minute trend yet, but that may be a user error.

Update Monday 15-May: Our version of NDS client is 0.10 and we need to have 0.14 for this new method to work. Ubuntu12 lscsoft repo doesn't have newer nds client so we'll have to upgrade some OS.

this is not the right one; this Ethernet controlled strip we want in the racks for remote control.

Buy some of these for the MONITORS.

1. Include several sources of error. Micrometer error is one, but you should be able to think of at least 3 more.
2. There should be an error bar for the x and y axis.
3. Also, use pdftk to put the PDFs all into a single file. Remove so much whitespace.
4. Google 'beautiful plots python' and try to make your plots for the elog be more like publication quality for PRL or Nature.

Good installation. I think the images are still out of focus, so try to resolve into some small dots at the low exposure setting.

A few weeks ago we did some internet speed tests and found a dramatic difference between our general network and our internal Martian network in terms of access speed to the outside world.

As you can see, the speed from nodus is consistent with a Gigabit connection. But the speeds from any machine on the inside is ~100x slower. We need to take a look at our router / NAT setup to see if its an old hardware problem or just something in the software firewall. By comparison, my home internet download speed test is ~48 Mbit/s; ~6x faster than our CDS computers.

controls@megatron|~> speedtest
/usr/local/bin/speedtest:5: UserWarning: Module dap was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path
  from pkg_resources import load_entry_point
Retrieving speedtest.net configuration...
Testing from Caltech (131.215.115.189)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Race Communications (Los Angeles, CA) [29.63 km]: 6.52 ms
Testing download speed................................................................................
Download: 6.35 Mbit/s
Testing upload speed................................................................................................
Upload: 5.10 Mbit/s
controls@megatron|~> exit
logout
Connection to megatron closed.
controls@nodus|~ > speedtest
Retrieving speedtest.net configuration...
Testing from Caltech (131.215.115.52)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Phyber Communications (Los Angeles, CA) [29.63 km]: 2.196 ms
Testing download speed................................................................................
Download: 721.92 Mbit/s
Testing upload speed................................................................................................
Upload: 251.38 Mbit/s

Right - we want to be compatible with new version of the code, so instead of moving the files to where the code wants them you should make symlinks. The symlinkks go in the place that the code wants and points back to the place where we have the files now.

For the textoverlay, you can just comment it out for now. We can add it back in later once we decide on how to label the video.

With the network config, mounting, and symlinks setup, rossa is able to be used as a workstation for dataviewer and MEDM. For DTT, no luck since there is so far no lscsoft support past the Ubuntu14 stage.

wonder if its possible that the slow glitches in MC are just glitches in MC2 trans QPD? Steve sometimes dances on top of the MC2 chamber when he adjusts the MC2 camera.

I've re-enabled the WFS at 22:25 (I think Gautam had them off as part of the MC2 glitch investigation). WFS1 spot position seems way off in pitch & yaw.

From the turn on transient, it seems that the cross-coupled loops have a time constant of ~3 minutes for the MC2 spot, so maybe that's not consistent with the ~30 second long steps seen earlier.

i wonder how 'HDR' these images really are. is there a quantitative way to check that we are really getting more bits? also, how many bits does the PNG format allow for monochrome images? i worry that these elog images are already lossy.

Indeed, the whole point of the high/low gain setup is to never use the QPDs for the single arm work. Only use the high gain Thorlabs PD and then the switchover code uses the QPD once the arm powers are >5.

I don't know how the operation procedure went so higgledy piggledy.