mafalda:SnapCode>CamSnap -F 'Mono8' -c 44058 -E 5000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw
-gray, height=480, width=752, bpp=8,depth=8,framerate=30/1 ! ffmpegcolorspace ! theoraenc ! oggmux ! filesink location="./testVideo.ogm"
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
** (gst-launch-0.10:27121): WARNING **: Size 60 is not a multiple of unit size 360960
Caught SIGSEGV accessing address 0x487c
ERROR: from element /pipeline0/ffmpegcsp0: subclass did not specify output size
Additional debug info:
gstbasetransform.c(1495): gst_base_transform_handle_buffer (): /pipeline0/ffmpegcsp0:
subclass did not specify output size
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7deddae in __lll_mutex_lock_wait ()
#2 0xb7de9aac in _L_mutex_lock_51 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb7de949d in pthread_mutex_lock ()
#4 0xb7e452e0 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0
#5 0xb7f1fa08 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#6 0x080c1220 in ?? ()
#7 0x00000001 in ?? ()
#8 0x0809586c in ?? ()
#9 0x00000001 in ?? ()
#10 0x08095868 in ?? ()
#11 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#12 0xb7e8da80 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#14 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#15 0x00000000 in ?? ()
Spinning. Please run 'gdb gst-launch 27121' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
Caught interrupt --
Alex brought over a ADC, DAC, and PCIe card which goes into the computer and talk to the IO chassis. We tried installing the new "small" IO chassis in 1X4, but initially it couldn't find the ADC/DAC boards, just the Contec Binary out board.
We tried several different configurations (different computer, different IO chassis, the megatron chassis, the megatron IO chassis with new cards, a new IO chassis with megatron cards.
The two things were concluded once we got a new IO chassis talking with the new computer.
1) Its possible one of the slots is in the IO chassis as we didn't see the ADC until we moved it to a different slot in the new chassis
2) The card that Alex had brought over to put in the computer doesn't behave well with these IO chassis. He went back to downs to try and figure out what it is, and test it with the chassis over there.
Currently, Megatron's IO chassis is sitting on a table behind racks 1Y5 and 1Y6, along with the new "large" IO chassis. Megatron's PCIe card for talking to the IO chassis was moved to the computer in 1X4. The computer in 1X4 is currently being called c1iscex with IP 192.168.113.80.
There has been a change in the default format for the output of the condor_q command at CIT clusters. This could be problematic for the summary page status monitor, so I have disabled the default behavior in favor of the old one. Specifically, I ran the following commands from the 40m shared account: mkdir -p ~/.condor echo "CONDOR_Q_DASH_BATCH_IS_DEFAULT=False" >> ~/.condor/user_config This should have no effect on the pages themselves.
I thought I'd get started on some of the tests tonight. But I found that this problem had resurfaced. I don't know what's so special about the REFL55 photodiode - as far as I can tell, other photodiodes at the REFL port are running with comparable light incident on it, similar flat whitening gain, etc etc. The whitening electronics are known to be horrible because they use the quad LT1125 - but why is only this channel problematic? To describe the problem in detail:
I request Koji to look into this, time permitting, tomorrow. In slightly longer term, we cannot run the IFO like this - the frequency of occurrence is much too high and the "fix" seems random to me, why should sweeping the whitening gain fix the problem? There was some suggestion of cutting the PCB trace and putting a resistor to limit the current draw on the preceeding stage, but this PCB is ancient and I believe some traces are buried in internal layers. At the same time, I am guessing it's too much work to completely replace the whitening electronics with the aLIGO style units. Anyone have any bright ideas?
Anyway, I managed to lock the PRMI (ETMs misaligned) using REFL165I/Q. Then, instead of using the BS as the MICH actuator, I used the two ITMs (equal magnitude, opposite sign in the LSC output matrix).
I didn't get around to running any of the other tests tonight, will continue tomorrow.
Update Mar 26: Attachments #2 and #3 show that there is clearly something wrong with the whitening electronics associated with REFL55 channels - with the PSL shutter closed (so the only "signal" being digitized should be the electronics noise at the input of the whitening stage), the I and Q channels don't show similar profiles, and moreover, are not consistent (the two screenshots are from two separate sweeps). I don't know what to make of the parts of the sweep that don't show the expected "steps". Until ndscope gets a log-scaled y-axis option, we have to live with the poor visualization of the gain steps which are dB (rather than linearly) spaced. For this particular case, StripTool isn't an option either because the Q channel as a negative offset, and I opted agains futzing with the cabling at 1Y2 to give a small fixed positive voltage instead. I will emphasize that on Friday, this problem was not present, because the gain balance of the I and Q channels was good to within 1dB.
In favor of keeping the same servo gains, I tuned the digital demod phases for the POX and POY photodiode signals to put as much of the PDH error signal in the _I quadrature as possible. The changes are summarized below:
The old locking settings seem to work fine again. This setting isn't set by the ifoconfigure scripts when they do the burt restore - do we want it to be?
Attachments #1 and #2 show some spectra and TFs for the POX/POY loops. In Attachment #2, the reference traces are from the past, while the live traces are from today. In fact, to have the same UGF as the reference traces (from ~1 year ago), I had to also raise the digital servo loop gain by ~20%. Not sure if this can be put down to a lower modulation depth - at least, at the output on the freq ref box, I measured the same output power (at the 0dB variable attenuator gain setting we nominally run in) before and after the changes. But I haven't done an optical measurement of the modulation depth yet. There is also a hint of lesser phase available at ~100 Hz now compared to a year ago.
I used the same fre swing data to diagnolize input matrices of following optics:
MC1, MC2, MC3
BS ETMX ETMY
AS1 AS4 SR2 PR2 PR3
For all these optics, the new input matrices worked well. Next step should be to take the local damping open loop transfer functions and standardize the loops to same UGF.
What didn't work:
All diagonalization results are present in https://git.ligo.org/40m/scripts/-/tree/main/SUS/InMatCalc
For looking at the results at this point, go to this commit: https://git.ligo.org/40m/scripts/-/tree/7ef6a47d1b2051a0732f46477624a9e625737fe8
I added a lockin to the LSC model, and added it's corresponding control to the LSC screen. Here's is what I added to the LSC model:
On the left are the froms from the normalized RF PD outputs. Those go into a matrix, whose single row goes into the lockin signal input. The clock output from the lockin goes into the LSC output matrix (last row).
Here is what I added to the LSC master screen:
I also modified the lockin overview screen:
I think this new screen looks a lot cleaner. Maybe we could start using this one as a template for lockin screens.
This is OK....but, the input matrix should come from the same place as the regular input matrix: i.e. it should be just another row like CARM, DARM, etc. rather than have its own screen.
Also, I think a nice mod to all the matrices would be if the ORANGE triangle was only visible when there's a signal flowing through it.
This is OK....but, the input matrix should come from the same place as the regular input matrix: i.e. it should be just another row like CARM, DARM, etc. rather than have its own screen.
You're absolutely right. That was a brain-fart oversight. I fixed the model so that the input from the lockin comes from another output row in the RFPD input matrix. I then fixed the C1LSC medm screen accordingly:
This is obviously much simpler and more straight-forward.
A future improvement would be to modify the DCPD input matrix to be able to route those signals to the lockin as well. This is actually currently possible since the DCPD input matrix is just a subset of the full input matrix, but it's not available via medm yet.
I went ahead and added the lockin output to the DCPD input matrix.
Let's use this entry to list of the test results of new donatella.
Jun 29, 2021 BIO I/F 6 units
Jul 19, 2021 PZT Drivers x2 / QPD Transimedance amp x2
Aug 17, 2021 2x ISC Whitening
Delivered 2x Sat Amp board to Todd
1. The rack we cleaned today (came from West Bridge) will be placed between 1X3 and 1X4, right next to 1X4 (after removing the plastic boxes). (Attachment 1)
For easier work at the side of the 1X4, the side panel of the 1X4 should be removed before placing the new rack. Note that this rack is imperial and has 10-32 threads
2. In terms of the other rack for the Y arm, we found the rack in the storage is quite dirty. Anchal pointed out that we have a few racks standing along the Y arm (as the storage of the old VME/Euro card electronics) (Attachments 2/3)
They are not too dirty and also doing nothing there. Let's vacate one of them (the one right next to the optics preparation table). Use this space as a new storage area placing a wire shelving rack for something.
BTW, I thought it is good to have the rack at the vertex side of 1Y1 (as 1Y0?), but the floor has "KEEP OUT" marking. I have no idea why we have this marking. Is this for crane operation??? Does any one know?
11 new Satellite Amps were picked up from Downs. 7 more are coming from there. I have one spare unit I made. 1 sat amp has already been used at MC1.
We had 8 HAM-A coil drivers delivered from the assembling company. We also have two coil drivers delivered from Downs (Anchal tested)
It is a belated report: We received 5 more sat amps on June 4th. (I said 7 more but it was 6 more) So we still have one more sat amp coming from Todd.
- 1 already delivered long ago
- 8 received from Todd -> DeLeone -> Chub. They are in the lab.
- 11 units on May 21st
- 5 units on Jun 4th
Total 1+8+11+5 = 25
1 more unit is coming
63% coupling efficiency into the new fiber collimator (Thorlabs XXXX) and the blue fiber.This should be sufficient for a beat measurement with the PSL laser.
I think the coupling efficiency is not too bad with having no mode matching lenses and no adjustable collimator lens.
252mW in front of the fiber
159 mW fiber output
The electronics chain used to drive the three elements of the PI PZT on which a mirror is mounted with the intention of controlling the LO phase has been changed, to now use the Trek Mode603 power amplifier instead of the OMC high voltage driver. Attachment #1 shows the new configuration.
The text of Attachment #1 contains most of the details. The main requirement was to map the DAC output voltage range, to something appropriate for the Trek amplifier. The latter applies a 50V/V gain to the signal received on its input pin, and also provides a voltage monitor output which I hooked up to an ADC channel in c1ioo. The gain of the interfacing electronics was chosen to map the full output range of the DAC (-5 to +5 V for a single-ended receiving config in which one pin is always grounded) to 0-2.5 V at the input of the Trek amplifier, so that the effective high voltage drive range is 0-125 V. I don't know what the damage threshold is for the PI PZT, maybe we can go higher. The only recommendation given in the Trek manual is to not exceed +/-12 V on the input jack, so I have configured D2000396 to have a supply voltage of 11.5 V, so that in the event of electronics failure, we still don't exceed this number.
On the electronics bench, I tested the drive chain, and also measured the transfer function, see Attachment #2. Seems reasonable (the Trek amplifier was driving a 3uF capacitive load used to protect the SR785 measurement device from any high voltage, hence the roll-off). The gain of D2000396 was changed from 1/8 to 1/4 after I realized that the DAC full range is only +/- 5 V when the receiving device is single-ended at both input and output. Maybe the next iteration of this curcuit should have differential sending, to preserve the range.
To test the chain, I used the single bounce beam from the ITM, and interfered it with the LO. Clear fringing due to the seismic motion of the ITM (and also LO phase noise) is visible. In this configuration, I drove the PZT mirror in the LO path at a higher frequency, hoping to see the phase modulation in the DCPD output. However, I saw no signal, even when driving the PZT with 50% of the full DAC range. The voltage monitor ADC channel is reporting that the voltage is faithfully being sent to the PZTs, and I measured the capacitance of the PZTs (looked okay), so not sure what is going on here. Needs more investigation.
Update Aug 30 5pm: Turns out the problem here was a flaky elbow connector I used to pipe the high voltage to the PI PZT, it had some kind of flaky contact in it which meant the HV wasn't actually making it to the PZT. I rectified this and was immediately able to see the signal. Played around with the dark fringe Michelson for a while, trying to lock the homodyne phase by generating a dither line, but had no success with a simple loop shape. Probably needs more tuning of the servo shape (some boosts, notches etc) and also the dither/demod settings themselves (frequency, amplitude, post mixer LPF etc). At least the setup can now be worked on interferometrically.
On Thursday, new huddle test data for the Wilcoxon 731A was aquired by Eric.
The difference between this new data and the previous data, is:
1) We used three accelerometers instead of six this time around.
2) We used a foam box, and clamped cables on the experimental set up as shown in the previous elog, http://nodus.ligo.caltech.edu:8080/40m/11389
I have analyzed the new data. Here I present my results.
The following plot shows the ASD's for the three accelerometers raw outputs as well as their error signals computed using the three cornered hat method,
As before, I computed the mean for the output signals of the accelerometers above as well as their mean self noise to get the following plot
Now, below I compare the new results with the results that I got from the old data,
Did the enclosure and cable clamping do much? Not really, according to the computed three hat results. Also, notice how much better, even if its a small improvement, we get from using six accelerometers and calculating their self noise by the six cornered hat method.
Now, I moved on to analyzing the same data with Wiener Filtering.
Here are again, the raw outputs, and the self noises of each individual accelerometer calculated using Wiener filtering,
The accelerometer in the Y direction is show a kind of funky signal at low frequncies. Why? Anyways, I calculated the mean of the above signals as I did for the three cornered hat method above to get the following, I also show the means of the signals computed with the old data using wiener filtering,
Is the enclosure really doing much? The Wiener filter that I applied to the huddle test old data gave me a much better, by an order of magnitude better self noise curve. Keep in mind that this was using SIX accelerometers, not THREE as we did this time. I want to REDO the huddle test for the WIlcoxon accelerometers using SIX accelerometers with the improved experimental setup to see what I get.
Finally, I compare the computed self noises above with what the manufacturer gives,
As I expected, the self noise using six accelerometers and Wiener filtering is the best I could work out. The three cornered hat method works out pretty well from 1 to 10 Hz, but the noise is just too much anywhere higher than 10 Hz. The enclosed, clamped, 3 accelerometer wiener filter result is an order of magnitude worse than the six accelerometer wiener filtered result, and two orders of magnitude worse than the three cornered hat method in the 1 to 10 Hz frequency band.
As I stated, I think we must performed the huddle test with SIX accelerometers and see what kind of results we get.
After munching analytical models, simulations, measurements of photodiodes I think I got a better grasp of what we want from them, and how to get it. For instance I now know that we need a transimpedance of about 5000 V/A if we want them to be shot noise limited for ~mW of light power.
Adding 2-omega and f1/f2 notch filters complicates the issue, forcing to make trade-offs in the choice of the components (i.e., the Q of the notches)
Here's a better improved design of the 11Mhz PD.
This should be better. It should also have larger resonance width.
How much is the width?
The transfer function phase drops by 180 degrees in about 2MHz. Is that a good way to measure the width?
To measure the width of a resonance, the standard method is to state the center frequency and the Q. Use the definition of Q from the Wikipedia.
As far as how much phase is OK, you should use the method that we discussed - think about the full closed loop system and try to write down how many things are effected by there being a phase slope around the modulation frequency. You should be able to calculate how this effects the error signal, noise, the loop shape, etc. Then consider what this RFPD will be used for and come up with some requirements.
I have updated the vacuum checklist for in vacuum alignment. Please take a look (https://wiki-40m.ligo.caltech.edu/vent/checklist) and see if I missed anything. My goal was to make it incredibly step-by-step so there can be no mistakes.
Here's a picture of where I am now inputting signals into the STACIS with the accelerometers (the orange and blue wires):
I know this is the right point because I could see the geophone signal from these points . By inputting a swept sine signal into this point, I was able to take a transfer function of this first amplifier/filtering circuit board, which will be useful if I need to make my own filter for the STACIS:
I have unplugged the geophones and am inputting a signal from an accelerometer into this point. The accelerometers output a different signal than the geophones, so I am trying to modify the accelerometer signal to be closer to the geophone one. I've lowered the gain on all the pots for the z axis and put in several BNC attenuators to lower the accelerometer signal amplitude.
At the moment, using the accelerometers as feedback makes the platform vibration worse, which will hopefully be solved by some more attenuation or filtering of the accelerometer signal.
I forgot to elog about these ones, my bad... The new/updated laptops are giada, viviana and paola; paola is already in the lab, while giada and viviana are in the control room waiting for a new home. The Pool of Names Wiki page has already been updated to reflect the changes.
Be aware that there is now a KEPCO HV supply that is energized, sitting on the floor immediately adjacent to the OMC rack, east of the AP table. It is currently set to 100 V DC, and a PI PZT installed on the AP table has its 3 PZTs energized by said supply (via an OMC piezo driver). I will post pictures etc of the work from the last 10 days over the weekend.
I locked PRMI, and (after fixing the POP QPD situation, noted in elog 9249) took power spectra of all the REFL RFPDs. It looks like the area above 500 Hz is pretty clean and flat for all the signals, so I'm going to use 560Hz, 562Hz, 564Hz, 566Hz and 568Hz for my 5 sensing matrix frequencies.
Also, I'm not sure what is going on with REFL11, but there's a weird dip between 630 Hz and 660 Hz in both I and Q. I recentered this guy not too long ago (elog 9218), but it clearly needs some more looking-at.
Still to do:
* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.
I worked today some more on the new Sensing Matrix situation. I have added stuff to the CAL model, so that the sensing matrix elements come out calibrated to W/m, with phase in degrees. The idea is that we can see time series of the calibrated lockin outputs, so that we have minimal post-processing to do, since these are things that will be interesting to look at live.
The first step is to go from I and Q to magnitude and phase. Each "sensor" (ex. REFL55Q) is demodulated with a lockin part, which outputs sub I and Q channels (so, something like REFL55Q_I and REFL55Q_Q). We are only interested in the _I component of the lockin. But, REFL55I also has a _I and _Q. Again, we only take the _I part. Now, we have REFL55I_I and REFL55Q_I. We call these the I and Q components of the sensors (this is exactly what we normally call them, but it can get confusing since the lockins also have _I and _Q before we discard the _Q part). Now, we want to take these I and Q components, and transform them to a magnitude and phase. After we do that, we want to calibrate the magnitude to "Watts per meter" from "counts sensed per counts driven". I also converted the phase to degrees, since that's the unit we usually use when talking about the sensing matrices.
To go from the I and Q components to Mag and Phase, I wrote a little block of c-code, which is in /opt/rtcds/caltech/c1/userapps/release/isc/c1/src/MagPhaseFromIQ.c . Since we can't use the arctan function, I approximated it using equation 17 from Full Quadrant Approximations for the Arctangent Function [Tips and Tricks] from IEEE. (I used x -> y/x in equation 17, so that I had a 2D situation). I also have an "if / else if" cascade to determine what quadrant I'm in. Since the formula in the paper is from [0,pi/2), I just needed to add pi, subtract the answer from pi, or negate the answer to get to the other quadrants. Also, note that they are using a "normalized" arctan function, so equation 17 is really from [0,1), and you have to remember to multiply by pi/2 on your own.
To get from drive counts to drive meters, I put in an EPICS variable for the optic's actuation constant (ex, PRM's constant can be found in elog 8255). Right now, we have to transfer the oscillation frequency from the oscillator part's _FREQ variable to a new EPICS variable, but Zach and Joe just today made a new oscillator part that makes it easier to access the frequency and amplitude of the drive within the front end. See LLO aLog 9139 for details on this new part. I had trouble compiling with their new part, but once I get that figured out, I won't need to do this transfer of information. Anyhow, the drive calibration is (optic actuation constant)/[(drive frequency)^2].
Then the total calibration of the magnitude is Mag in cts/m = 2 * mag / [(drive amplitude) * (drive calibration)] . The factor of 2 comes from the fact that the lockin output is a factor of 2 smaller than the true sensing matrix element. The lower case "mag" in the formula is the output of the c-code.
After this, there is yet another EPICS variable, to hold the calibration for the photodiode, to get from counts sensed to Watts of power at the actual port. By "actual port", I mean the true IFO port, taking into account any optical elements between the port and the photodiode, like beam splitters and dumps, or loss from the imperfect reverse isolation of the input Faraday.
The code all compiles and runs fine, although I haven't done any explicit testing yet.
Still to-do for Sensing Matrix:
* Find all of the numbers for all of the EPICS variables. In particular, I need to get the ratio of the power hitting each photodiode to the power at that port.
* Write a script to do a burt-restore with all the correct settings, and turn on the dither lines.
* Put the lowpass filters back in the demodulators, now that they have new (shorter) names.
* Try it, and compare with the optickle model, and previous measurements.
* Copy Anamaria's script to look at the error statistics for my measurements.
I have modified the Sensing Matrix I,Q to Mag, Phase library part in the new sensing matrix system.
I had forgotten that in the c-code, I convert from radians to degrees, and so was doing the conversion again in the model. As it turns out, this gives you a nonsense number. I removed the multiplication by 180/pi in the model, and just use the output of the c-code, which is already in degrees.
I also put in some "choice" blocks just before the divisions in the calibration section of this library part. If it's about to divide by zero, divide by one instead.
The last modification so far today was adding the _PHASE_DEG and _MAG_WPERM (watts per meter) channels to a DAQ channels block, so that they are saved.
The RCG was very unhappy with me having 2 channels, with no data rate after them (doing this is supposed to imply that both should be saved at the default data rate), however after I put in "2048", it was happy. The symptom was a little tricky: The channel names in Dataviewer showed up red, even though the model compiles and runs. An indicator that you have a problem is a note in the model's "GDS" screen (the details screen that you can click to from the CDS front end overview screen). The channel name is "C1:FEC-50_MSGDAQ" (where the number 50 is specific to the c1cal model). After restarting the model, but before restarting the framebuilder's daqd process, this channel said "Error reading DAQ file!", rather than the date and time of the last successful read. At this point, before restarting the daqd process on the framebuilder, all of the fb statuses are green and good. However, after restarting the daqd process on the framebuilder, I got status "0x2000". Anyhow, after trying many different things, I determined that I could have 1 channel, without a specified rate, but if I wanted more than one channel, I needed to specify the rate for both.
After finishing up working on the models for today, I made corresponding screens.
The new Sensing Matrix (and lockin) overview screen is accessible from the sitemap: LSC -> Sensing Matrix.
From there, you have the oscillators, input matrices (one per degree of freedom), output matrix, and the lockin modules themselves. You can either look at several PDs for one degree of freedom (ex. there is a screen for all the AS RFPDs, demodulated for the DARM oscillation), or all the degrees of freedom for a single PD (ex. how are all the degrees of freedom seen in AS55Q?). The LSC screen has been updated to match - now you see 5 oscillator readbacks, and a larger output matrix. There is a button for the Sensing Matrix overview screen, and if you click on the cartoons of the oscillators, it'll take you to the oscillators screen.
* Decide what 5 frequencies to use for excitation.
* Put the bandpass and lowpass filters into the lockin modules.
* Put matching notch filters into each LSC servo.
* Re-write the sensing matrix scripts.
I worked on some of these "to-do" things today for the new sensing matrix setup. I chose several frequencies around 90 Hz for my measurements. This was an area (while PRMI was locked with REFL 165 I&Q, and all 4 REFL PDs had their whitening on) there was a pretty wide clean space in the noise spectrum.
I put bandpass filters into the _SIG banks of the lockin modules, and lowpass filters into the _I banks. However, when I loaded the new filter coefficients, it looks like not all of them are showing up in the screens. I'm a little confused as to why. They are still there if I close and re-open Foton, so I think I really put them in.
Also, I don't think that I'm successfully getting any signal from the LSC model into the new lockin modules on the CAL model. I'm not sure if this is to do with the fact that I added 32 more IPC connections the other day. I've emailed Jamie to ask whether or not we may have hit some limit.
I also tried testing out a small bit of c-code for the calibration of the lockin outputs. It seems as though I cannot do an arctangent in the front end. When I compile the c1tst model, and start it up, if I have an "atan2" in the code, it tells me "No Sync". However, if I remove that line of c-code, the model compiles fine (which it did in the case with the arctan), and the model runs just fine (which it doesn't with the arctan). My backup plan is to include a Taylor expansion for the arctangent in some c-code.
I think that we always drive above the UGF for sensing matrix measurements since we like to put notches in the servo. In principle, we could drive within the control band and then take out the effect by measuring the control signal and undoing the gain in the digital filters. But that seems pretty complicated for any MIMO system.
Hmmmm, yup. I forgot to pay attention to what the UGFs of our LSC loops are when I was picking a low-noise region. Since they're (currently, at least) around 100Hz, I want to find a frequency in the few hundred Hz region. Masayuki has the IFO right now for ALS diagnostics, so I'll pick new frequencies later. If we decide to omit the bandpass filters, it's even easier to change frequencies on the fly (although we'll always still have to make the servo notch filters match).
After staring and thinking, I remembered that there is a limit to the number of characters that a channel name can have. So, I removed the "_LOCKIN" part of the names, and recompiled, and everything seems to work. I modified the screens that I had made, and they show all the appropriate things now.
The symptoms were that the numbers in the filter banks (for example, INMON) were white with the usual black background. The numbers are supposed to be green with a black background. After I recompiled, all the numbers were green.
This also means I need to re-put in the low pass filters.
I implemented most of the things outlined in my previous elog. Implementing the a la mode solution after including all lenses, I managed to achieve >90% mode-matching into the fiber. Power monitor PD has not been re-installed yet, neither has the bracket I removed. The polarization monitoring setup on the PSL table has now been hooked up to the EX fiber, let's see how it does overnight. All quoted power measurements in this elog were made with the Ophir power meter (filter off).
Attachment #1 shows the implemented MM solution. I did not include the PBS substrate in the calculation, maybe that will help a little.
Attachment #2 shows the new layout. The beam is a little low on the PBS and HWP - I will swap these out to mounts with slightly lower height, that should improve the situation a little. There is no evidence of clipping, and the beam clears all edges by at least 3 beam diameters.
Attachments #3 and #4 show the EX fiber before and after cleaning respectively. Seems like the cleaning was successful.
Attachment #5 shows the beam incident on the coupler with on an IR card. This beam only goes through a QWP, lens, BS and 45 degree steering mirror, so I'm not sure what's responsible for the large halo around the main beam. There is significant power in the halo too - I measured 25mW right before the coupler, but if I use an iris to try and cut off the halo, the power is measured to be ~19mW.
Here is a first look at the overnight stability. For the temperature, I used the calibration I found in the old psl database file, seems to give sensible results. It's only 15 hours of data plotted, so we don't see the full 24 hour temperature swing, but I think it is safe to say that for the EX fiber, the dominant cause of the "waveplate effect" is not in fact temperature drift. The polarization extinction is still better than 10dB in the entire period of observation though... I'm going to push ahead with a beat spectrum measurement, though there is room for improvement in the input coupling alignment to fiber special axes.
The apparent increase in these plots towards the end of the 15 hour period is because the lights on the PSL table were switched on.
Annoyingly, it seems like the PSL NPRO channels (which I have hijacked to do this test) do not have minute trend data directly accessible from NDS2. Not sure whether this is an NDS2 problem, or something missing in the way the channels are setup with Acromag. Probably the former, as I am able to generate minute trend plots with dataviewer. I forget whether this is the same as the infamous minute trend problem. Second trend data is available though, and is what I used to make these plots...
Yesterday, I made new mounts for microphones.
I glued a microphone on a pedestal. The cables are attached loosely so that its tension does not make any noise.
At the bottom of the mount, I attached the surgical tube forming a ring by double-side tape so that it damps the seismic vibration.
I made 6 mounts and these are all on the AS table now.
I took some data of XARM signal controlled by AS.
My plan is to find/set an upper limit on acoustic coupling noise in AS signal.
The acoustic noise can be estimated by the Wiener filter, but it is not accurate because it may see residual correlation between AS and microphone signals that should be 0 when the data is long enough.
I will find/set an upper limit by the analysis based on Neuman-Pearson criterion, that is analog of a stochastic GW background search.
If I can find the acoustic coupling noise should be below the shot noise, I am happy. If not, some improvements may be needed someday.
Since Den wasn't able to fix c1sus (make it talk to the framebuilder) before he left a few hours ago, I decided to do some housekeeping rather than actual locking.
I wrote new save / misalign / restore scripts for all of the suspended optics on the C1IFO_ALIGN screen. Adding save / restore versions for the mode cleaner optics should be quick and easy. Now when you use the ! button for each optic, it points you to the new scripts. I still have the burt capabilities there, but the restore script has the burt-restore line commented out.
SAVE: burt-save the PIT_COMM and YAW_COMM values, as well as write those values and the date to a text file.
MISALIGN: Turn off oplevs, move 100 steps of 0.01 in the "+" direction.
RESTORE: Move ~100 steps toward the saved value, until you're within 0.001 of the saved value (step size is "saved val" minus "current val" divided by 100). Then just write the saved value to the slider (otherwise if the slider were touched between the last "save" and the restore, we might not be able to step precisely to the value we want). Turn oplevs back on.
Scripts are in the same place the old ones used to live: ...../caltech/c1/medm/c1ifo/cmd/ New scripts are C1IFO_OPTIC(save/restore/misalign)_soft.cmd
I'm checking this one off of the to-do list.
Good things: (a) I remembered / re-learned / just plain learned a lot about scripting. (b) the optics are now walked slowly over to their misaligned state, and slowly walked back. The past regime had the optics suddenly kicked over by a lot, sometimes enough to trip / come close to tripping watchdogs, which was never good.
Bad things: it took a long time. Now it's bedtime.
I have made a new model for the endtable PZT servo, and have put it in c1iscex. Model name is c1asx. Yesterday, Koji helped me start the model up. The model seems to be running fine now (there were some problems initially, I will post a more detailed elog about this in a bit) but some channels, which are computer generated, don't seem to exist (they show up as white blocks on the MEDM GDS_TP screen). I am attaching a screenshot of the said screen and the names of the channels. More detailed elog about what was done in making the model to follow.
C1:DAQ-DC0_C1ASX_STATUS (this is the channel name for the two leftmost white blocks)
I don't know what's going on here (why the channels are white), and I don't yet have a suggestion of where to look to fix it but...
Is there a reason that you're making a new model for this? You could just use and existing model at c1iscex, like the c1scx, and put your stuff in a top-names block. Then you wouldn't have to worry about all of the issues with adding and integrating a new model.
I have made some minor changes to the model, made all the MEDM screens, and linked monitors on these to the appropriate channels. I have borrowed heavily from the C1ASS MEDM screens (particularly for the small filter modules-it was convenient to just copy and paste an existing module, and edit the channel names using EMACS/GEDIT), and have edited these to suit the needs of this servo. Some features:
I think I am now ready to take some measurements and try and optimize this servo. There is no green transmission at the PSL table at the moment, so not much can be done, though the first step would be to take the power spectrum of the error signal, which would help me decide the appropriate frequencies for the LOs. I would then have to add the appropriate filters to the model. The last, and most difficult step, would be the measurement of the output matrix, though Koji has given me some ideas about how this measurement can be done. I also have a template script ready, though I will only finalise this after optimising the servo and running it a couple of times manually.
Attached are screenshots of the MEDM screens.
Koji just fixed this.
It seems that the new model's channels were not automatically added to the master file in the framebuilder (/opt/rtcds/caltech/c1/target/master). Adding the following two lines to the master file fixed the problem;
The box is now green. It looks like C1ASX.ini is created automatically in /opt/rtcds/caltech/c1/chans but the master file needs to be manually edited. The channels are now showing up on dataviewer etc. I have updated the information on the wiki page.
These are roughly the steps I followed in setting up the new model for the endtable PZT servo - C1ASX.
I made a SIMULINK model of the servo, using MATLAB R2013a. The path to the model is /opt/rtcds/caltech/c1/userapps/release/isc/c1/models/c1asx.mdl. I am listing the parameters set on the CDS_PARAMETERS block:
Making, Compiling and Installing the Model:
After saving the model, I ssh-ed into c1iscex and ran the following commands:
rtcds make c1asx - this gave me a whole bunch of errors initially, which I tracked down to a naming problem in some of the from and goto flags: there should not be any spaces.
rtcds install c1asx
rtcds start c1asx - this gave me an error which said something like 'can't start/stop model.' Koji pointed out that given that a new model is being started, there is an additional step involved, which is to add the model name to the rtsystab file (this is located at /diskless/root/etc/rtsystab on framebuilder, and is mirrored in the various computers. It would be advisable to make sure that the changes are mirrored in the corresponding file on the computer in which the new model is being installed).
After adding the model name to the rtsystab file, I tried running rtcds start c1asx again. This time, no errors were output, but the model was not up and running as verified by looking at the C1:ASX_GDS_TP medm screen.
Koji suggested making a simple model (1 CDS parameters block, 1 ADC block and 2 filter modules, appropriately terminated) and see if that starts up, which it did. I then tried adding my servo minus the DAC block and recompiled and restarted the model. This too worked fine. I figured that the next logical step would be to add the DAC block to the model, and restart the model. But when I tried this, c1iscex crashed .
Jenne helped in restoring things to a working state (we reverted the c1asx model to just 2 filter modules, and went to the X-end and restarted the computer. This did not work the first time so I went back in and restarted it again, at which point we were able to ssh into c1iscex again and restart the four models running on it).
Since Manasa and Koji were working on getting things set up for the pumpdown,I did not try anything again till later in the evening, when Koji helped in debugging the problem further. In the meantime, at Jenne' suggestion, I made the model once again in MATLAB R2010b. In the evening, when I tried restarting the model, Koji suggested that the DAC channels in c1asx may be used by other models, at which point I realised I had set up excitation points on channels 8 through 15 of the DAC in c1scx (detailed here) in order to test the hardware at 1X9. I removed the excitation points from channels 8-11 of the DAC block in c1scx (these are the ones used in c1asx), and recompiled and restarted c1asx (using the above sequence of commands). I then tried recompiling and starting c1asx once more, and this time, it worked . At least, the GDS_TP screen suggests that the model is running alright, except for the fact that some computer generated channels seem to be missing. This problem is unresolved for now, and probably has something to do with the fact that C1ASX channels do not appear in Dataviewer.
I do not think this has to do with restarting framebuilder (I did the usual telnel fb 8088 followed by shutdown). In any case, I have added the new model to the CDS_FE_STATUS screen, and will continue to debug the same. I have also got a template medm screen (work in progress) which I will elog about soon as I get it done.
Note to self: There are 4 more excitation channels still hooked up to the DAC (channels 12-15) in the c1scx model. I plan to remove these and put them in c1asx.
Using all of the latest parameters that I can find, I have re-modeled the 40m sensing matrix. Also, I have it output the data in a format that can be used by the same plotting function as the measured sensing matrix, so they are nice and easy to compare.
The newly modeled 40m sensing matrix:
To compare, here is the measured sensing matrix from elog 8644:
Notice that (a) the units are different, so don't focus too much on the amplitudes of the lines, and (b) all of the measured and modeled matrix elements are pretty similar, except for the REFL11. REFL11 (top right in model plot, top center in measured plot) looks like it's flipped, as well as rotated. The new model doesn't match up too well with the Kiwamu/Koji models (which matched eachother okay), but I like that the new model matches the measurements fairly well. The Koji sensing matrix: on the 40m wiki
EDIT: I have replaced the modelled plot with a new version. The data and numbers are the same, but I have switched the labels on the individual radar plots, and forced them to be in the same order as they are in the measured plot.
I'd repeat the measurement for REFL11. The PRC arrow has some big error bar on it, and maybe the true error is even bigger.
Also, please make the placement of the plots the same for modeled and measured so it's easy to compare.