As EQ pointed out recently, we're injecting into the FSS error point just after an RF pi filter, but before the VGA. We wondered what the weird filter impedance was doing to our signal if we inject after it. I used LISO to model this FSS common section and attach the plots.
The first plot shows the TF between the Test 1 input and the AD602 VGA input. This is NOT the input that we are actually using.
The second plot shows the TF between the IN1 port (which we are actually using) and the VGA input.
Neither of them shows the 1 MHz bump that we see in the measurements, so I suspect that the board has been modified...the hunt continues. We've got to pop the top of the TTFSS and take photos and measure from IN1 to VGA input.
** FSScomm.fil is now in the LISO SVN. The following command line will run it with two different cases and cat the PDF files into one. If you use an auto-refresh PDF viewer like Okular or Mac Preview, its a nicer display than the usual GNUplot window:
./mfil FSScomm.fil; sleep 1; pdftk FSScomm_run*.pdf cat output FSScomm.pdf
The script for running continuous scans on HP 8591E spectrum analyzer is located at scripts/general/netgpibdata/HP8591E_contdScan.py
There was no such script in the directory when I looked today, but I found one called HP8591E. Of course, it didn't run because it hadn't been tested from the scripts directory and pointed to some /users/nichin/ stuff.
I modified a couple of lines and then committed it and the default .YML parameter file to the SVN. It runs and produces plots continuously from the scripts directory.
*** also, as you can see, we have mostly recovered the green beat amplitudes after yesterday's FLL attack on the ALS ***
When the IMC locks, we want the FAST OUT of the TTFSS box to be close to zero volts. We also want the control signal from the MC Servo board to be close to 0 V. How to set this up?
With the IMC locked, we just servo the FSS input offset to minimize the MC board output :
ezcaservo -r C1:IOO-MC_FAST_MON -g 0.1 -t 10 C1:PSL-FSS_INOFFSET
I would have used "CDSUTILS", but that seems to have some sort of ridiculous bug where we can't have prefixes on channel names, even on the command line.
Mech Resonance Wiki
I've updated the wiki by trawling the elog for violin entries. Please keep it up to date so that we can make violin notches.
We used to do violin mode and test mass body mode notches in the SUS-LSC filter modules. Now we want them balanced in the LSC and triggered by the LSC, so they're in the filter modules which go from the the LSC output matrix to the SUS.
Today, we were getting ETM violin mode ringups while doing ALS hunt and so we moved the bandstops into the LSC. I also changed the bandstop from a wide one which missed the ETMX mode to a double bandstop which gets both the ETMX and the ETMY mode. See attached image of the Bode mag.
To help development of the data visualization project, we've assigned the .101 and .102 IP to DataVis. This is being used by the iMac in the control room via port 8 of the CDS switch near the Blue Plataeu Tournant.
We tried using one of the free ports, but Jamie realized that we had to use one of the already assigned ones due to some 'Smart' switch management software. So for the moment, please leave the iMac alone so that Bill can use it.
I've been having trouble locking the X - green for the past few hours. Has there been some configuration change down there that anyone knows about?
I'm thinking that perhaps I need to replace the SHG crystal or perhaps remove the PZT alignment mirrors perhaps. Another possibility is that the NPRO down there is going bad. I'll start swapping the Y-end NPRO for the X-end one and see if that makes things better.
What monitor point is being plotted here? Or is it a scope probe output?
If this saturation is in the uPDH-X but not in the uPDH-Y, then just replace the VGA chip. Because these things have fixed attenuation inside, they often can't go the rails even when the chip is new.
In any case, we need to make a fix to get this box on the air in a fixed state before tomorrow evening.
I had noticed in the past, that the digital control signal monitor for the X end would saturate well before the ADC should saturate (C1:ALS-X_SLOW_SERVO_IN1, which is from the "output mon" BNC on the box). It turns out that there is some odd saturation happening inside the box itself.
In this scope trace, the servo input is being driven with a 0.02Vpp, 0.1Hz sine wave, gain knob at 1.0. This is bad.
Evan and I poked around the board, and discover that for some reason currently unknown to us, the variable gain amplifier (AD8336) can't reach its negative rail, despite the +-12V arriving safely at its power supply pins.
I also realized that the LF356 in the integrator stage in this box had been replaced with a LT1792 by Kiwamu in ELOG 4373. I've updated my schematic, and will upload both boxes' schematics to the DCC page Jenne created for them. (D1400293 and D1400294)
I gave the IPs to the bridges. According lines of /etc/hosts in linux1 were updated.
I was going through some old Koji elogs to check them for correctness (as I do weekly). I noticed that back in Dec 2013, he made the above illegal modification of IP numbers. 192.168.113.230 was actually the IP for farfalla. Maybe that's why they were conflicting and farfalla not working and Q observing/imagining wireless GPIB dropouts?
I used the Wiki instructions to update the 2 bind9 files with a new number for farfalla (192.168.113.212) which was previously the number for the long dead op240m. Farfalla is restarted and sort of working.
I re-centered the ITMX & ITMY Optical lever beams today since they were off. First I aligned the beam into the vacuum so that it went through the center of the on table optics and then tweaked the receiver optics alignment.
There are several bad practices on these which probably makes them drift:
According to the datasheets, the laser has a beam diameter of 0.6 mm and a divergence angle of 1.3/2 mrad. So we can just calculate the right lens positions next time and not have to experiment with the whole visible laser lens kit.
For next Wednesday's cleanup, someone should volunteer to make the mounts more stable for the ITMs.
I changed the Martian wireless router to use channel 10 instead of something random (as it was). Using the Android app 'Wifi Analyzer' we could see that the usual channels are dominated by FlumeLab and Caltech Beaver.
The range from 9-13 looked clean so we put it up there. Also, the signal strength drops from -45 to -70 dBm as we walk from the BS down to the ends. We need to tweak the router position and orientation to give us another 10 dB so that we can reliably run the laptops at the ends.
Does this matter? Is there something in my simulation that I can correct that would give a more accurate calibration?
Data, plots, code, attached.
What modulation depth are you using for the simulation? I have never seen a real measurement of that in our elog for the end-PDH systems.
I also disbelieve your RMS calculations. It looks like in the 1.5-0.5 Hz band we're picking up 50 kHz of frequency noise even though the 1 Hz peak is only 80 Hz/rHz, even though math says "80 * sqrt(1) = 80".
Take a look at:
600 Hz seems ~OK. From the measured reflectivities for 532 nm, the green Finesse = 108. So the green cavity pole should be 18.3 kHz given an arm length of 37.8 m.
600 Hz of green frequency noise means that we would get 38 pm RMS of arm mirror motion. We should assumed a peak/RMS factor of 10, so this would allow us to get to ~0.4 nm CARM offset.
However, its better than that. What we really care about for ALS is the amount of this green frequency noise which is put onto the arm. With an ALS feedback bandwidth of 100 Hz, my eyeball estimate say that the contribution from green PDH error will be ~100 Hz RMS, since we don't care too much about the 10 kHz stuff. So this seems good enough for now; let's figure out what's up with PDH-Y and get back to locking.
FYI: in that rack, the +15V pulls ~0.5 A more than -15V usually. I think this is due to some RF amplifiers which are powered by this (e.g. the AOM that Manasa set up). The Sorensen's can source ~30A in principle, so we should make sure to set the current limit appropriately so as to not overheat them when there is a short.
Was this power supply not fused for all of its connections? I remember that this was connected to at least one un-fused connection in the past year.
Today the network connection of OTTAVIA was sporadic.
Then in the evening OTTAVIA lost completely it. I tried jiggle the cables to recover it, but in vain.
We wonder if the network card (on-board one) has an issue.
I would also suspect IP conflicts; I had temporarily put the iMac on the Ottavia IP wire a few weeks ago. Hopefully its not back on there.
Dan Kozak is rsync transferring /frames from NODUS over to the LDAS grid. He's doing this without a BW limit, but even so its going to take a couple weeks. If nodus seems pokey or the net connection to the outside world is too tight, then please let me and him know so that he can throttle the pipe a little.
It seems clever, but I wonder why use DTT and command line perl, instead of using the FE lockins or just demod the offline data or all of the other sensing matrix scripts made for the LSC (at 40m) or ASC (at LLO) ?
Assuming that these Watts/Newtons TFs are correct, I've modeled the resulting open loop gain for CARM. The goal is to design a loop that is stable under a wide range of offsets and also has enough low frequency gain.
The attached PDF shows this. I used a CARM OLG Simulink model:
I've replaced the 'armTF' block with a digital gain of zero. After measuring the open loop gain of all but this piece, I multiply that 'OLG' with the W/N that Jenne extracted from Optickle for CARM->TR (not sqrtInv)
I plot the resulting estimate of the actual OLG in the following plot. Since the CARM-RSE peak is moving down, we use the LP filter that Den installed for us several months ago. To account for the radiation pressure spring, we use some low frequency boosts but not the crazy FM4 filter.
As you can see, the loop is stable from 500 to 200 pm, but then goes unstable around 110 pm. I expect that we will want to do some fancy shaping there or switch from TRX+TRY into something else.
This assumes we have filters 0, 1, 3, 5, and 7 on in the CARM filter bank - still need to add the digital AA/AI to make the loop phase lag a little more accruate, but I think this is looking promising.
Since no one was here, I started the Ubuntu 10 - 12 upgrade on Rossa. It didn't run at first because it wanted to remove 'update-manager-kde' even though it was on the blacklist. I removed it from the command line and now its running. Allegra, OTOH, refuses to upgrade. Someone please ask Diego to wipe it and then install Ubuntu 12 LTS on there in the morning...its a good way to learn the Martian CDS setup.
In my previous elog in this thread, I showed the CARM OLG given some new digital filters and the varying CARM plant (spring side, not anti-spring). Jenne has subsequently produced the TFs for all of the rest of the CARM offsets.
These attached plots for several CARM offsets show that the anti-spring side is much more stable than the spring side and so we should use that. Annecadotedally, we think that positive CARM offsets are more stable when going to arm powers of > 10, so perhaps this means that +CARM = -SPRING.
The first PDF shows the spring OLGs and the 2nd one shows the antispring OLGs. I have put in some gain changes to keep the UGF approximately the same as the offset is changed.
The PDF thumbnails will become visible once Q and Diego install the new nodus.
UPDATE OCt 16: this is all wrong! bad conversion of filters within the invbilinear.m function.
I think these are all very helpful and interesting plots. We should see some better performance using either of the DC DARM signals.
BUT, what we really need (instead of just the DC sweeps) is the DC sweep with the uncertainty/noise displayed as a shaded area on the plot, as Nic did for us in the pre-CESAR modelling.
Otherwise, the DC sweeps mistakenly indicate that many channels are good, whereas they really have an RMS noise larger than 100 pm due to low power levels or normalization by a noisy signal.
In my last CARM loop modelling, all of the plots are phony, so don't trust them. The invbilinear function inside of StefanB's onlinefilter.m was making bogus s-domain representations of the digital filter coefficients.
So now I've just plotted the frequency response directly from the z-domain SOS coeffs using MattE's readFilterFile.m and FotonFilter.m.
Conclusions are less rosy. The anti-spring side is still easier to compensate than the spring side, but it starts to get hopeless below ~130 pm of offset, so there we really need to try to get to REFL_11/(TRX+TRY), pending some noise analysis.
** In order to get the 80 and 40 pm loops to be more stable I've put in a tweak filter called Boost2 (FM8). As you can see, it kind of helps for 80 pm, but its pretty hopeless after that.
This is looking very useful. It will be useful if you can upload some python code somewhere so that I can muck with it.
I would guess that the right way to determine the trans RMS is just to use the single arm lock RIN and then apply that as RIN (not pure TR RMS) to the TR signals before doing the sqrt operation.
10% seems like a pretty bad coupling efficiency, even for a single lens. I know that the NPRO itself isn't so elliptical as that. Where is the other 230 mW going? random scattering?
Given that this is such an invasive process and, since its so painful to lose a whole night of locking due to end table business, I suggest that you always measure the out-of-loop ALS noise at the end of the end table work. Just checking that the green laser is locked to the arm is not sufficient to prove that the end table work won't prevent us from locking the interferometer.
We should insist on this anytime someone works on the optics or electronics at EX or EY. Don't have enough time to do an out-of-loop ALS spectrum? Then don't work at the end tables at all that day. We've got PZT alignment and mode matching work to do, as well as the rebuild of the EX table enclosure, so this is a good discipline to pick up now.
I've fallen down the rabbit hole of trying to reconcile our desire for newer versions of the Numpy and Scipy python packages with the use of our handy cdsutils tools.
Avoid rabbit holes! What I did at LLO which works is to install an Anaconda in some shared directory and then just make an alias which puts that directory at the head of the path when running the more advanced SciPy installs. It works fine and cannot interfere with our usual operation since its only sourced when running peak find.
I think 'saturation' here is a misleading term to think about. In the RF amplifiers, there is always saturation. What we're trying to minimize is the amount of distorted waveforms appearing at 3f and 15f from the other large peaks. Usually for saturation we are worried about how much the big peak is getting distorted; not the case for us.
I modified the MC2 trans optical setup a little bit: the reflection from the QPD was not dumped and so it was hitting the wall of the black box.
I angled the QPD slightly and moved the dump so that the reflection hit it. The leakage through the 50/50 steering mirror for the QPD was already being dumped and I made sure that that one stayed dumped on its razor dump. After doing this we turned off the WFS and re-aligned the MC2 trans beam onto the QPD to zero the pit/yaw signals.
In order to do high quality huddle subtraction, we need to align the seismometer axes to high precision. We would need 1000x subtraction to see the instrument noise floor, but are likely to only get 100x. For that we need to align the axes to 0.5 deg (or do a Wiener coordinate transform with the data). To do this, we need to use a high quality bubble level and eventually iterate after trying out.
We should strain relieve the seismometer cables on the slab. It should be a tight clamp so that acoustic vibrations on the cables are terminated at the clamp and don't get to the seismometers. The clamp can be attached to the slab using some strong epoxy.
I modified the /cvs/cds/caltech/target/c1psl/psl.db file to adjust the records for the FSS-FAST signal (to make it go yellow / red at the correct voltages). This was needed to match 5V offset which Koji added to the output of the FSS board back in August.
I also manually adjusted the alarm levels with caput so that we don't have to reboot c1psl. Beware of potential tiimebomb / boot issues if I made a typo! psl.db update in the SVN (also, there were ~12 uncomitted changes in that directory....please be responsible and commit ALL changes you make in the scripts directory, even if its just a little thing and you are too cool for SVN)
All of the QPDX matrix fields had a missing underscore in them. So I committed all of the c1asc screens to the SVN (because no one but me and Jamie seems to be able to remember to do this).
Then I did find/replace on the QPDY screen and saved it over the QPDX screen and committed the new thing to SVN as well. Values are now accessible.
16 bit. There aren't any 14-bit ADCs anywhere in LIGO. The aLIGO suspensions have 18-bit DACs.
The Y-End gains seem reasonable to me. I think that we only use TRX/Y as error signals once we have arm powers of >5 so we should consider if the SNR is good enough at that point; i.e. what would be the actual arm motion if we are limited only by the dark noise?
I seem to remember that the estimate for the ultimate arm power is ~200, considering that we have such high losses in the arms.
Found that the PMC gain has been set to 5.3 dB instead of 10 dB since 9 AM this morning, with no elog entry.
I also re-aligned the beam into the PMC to minimize the reflection. It was almost all in pitch.
What we want is to have the high and low noise spectra on the same plot. The high noise one should be triggered by a high PC DRIVE signal.
I've updated the scripts for the MC auto locking. Due to some permissions issues or general SVN messiness, most of the scripts in there were not saved anywhere and so I've overwritten what we had before.
After all of the electronics changes from Monday/Tuesday, the lock acquisition had to be changed a lot. The MC seems to catch on the HOM more often. So I lowered a bunch of the gains so that its less likely to hold the HOM locks.
A very nice feature of the Autolocker running on megatron is that the whole 'mcup' sequence now runs very fast and as soon as it catches the TEM00, it gets to the final state in less than 2 seconds.
I've also increased the amplitude of the MC2 tickle from 100 to 300 counts to move it through more fringes and to break the HOM locks more often. Using the 2009 MC2 Calibration of 6 nm/count, this is 1.8 microns-peak @ 0.03 Hz, which seems like a reasonable excitation.
Using this the MC has relocked several times, so its a good start. We'll have to work on tuning the settings to make things a little spicier as we move ahead.
That directory is still in a conflicted state and I leave it to Eric/Diego to figure out what's going on in there. Seems like more fallout from the nodus upgrade:
controls@chiara|MC > svn up
svn: REPORT of '/svn/!svn/vcc/default': Could not read chunk size: Secure connection truncated (https://nodus.ligo.caltech.edu:30889)
In the plot it is shown the behaviour of the PSL-FSS_SLOWDC signal during the last week; the blue rectangle marks an approximate estimate of the time when the scripts were moved to megatron. Apart from the bad things that happened on Friday during the big crash, and the work ongoing since yesterday, it seems that something is not working well. The scripts on megatron are actually running, but I'll try and have a look at it.
I reset the threshold to +6666 counts (the aligned MC transmission is ~16000 for the TEM00 mode) so that it only turns on when we're in a good locked state.
Koji and I noticed that there was a comb* of peaks in the MC and FSS at harmonics of ~37 kHz. Today I saw that this shows up (at a much reduced level) even when the input to the MC board is disconnected.
It also shows up in the PMC. At nominal gains, there is just the 37 kHz peak. After tweaking up the phase shifter settings, I was able to get PMC servo to oscillate; it then makes a comb, but the actual oscillation fundamental is 1/3 of 37 kHz (some info on Jenne from elog 978 back in 2008).
Not sure what, if anything, we do about this. It is curious that the peak shows up in the MC with a different harmonic ratio than in the PMC. Any theories?
Anyway, after some screwing around with phase and amplitude of the RF modulation for the PMC from the phase shifter screen**, I think the gain is higher in the loop and it looks like the comb is gone from the MC spectrum.
Another clue I notice is that the PCDRIVE mad times often are coincident with DC shifts in the SLOWDC. Does this mean that its a flakiness with the laser? While watching the PCDRIVE output from the TTFSS interface board on a scope, I also looked at MIXER mon. It looks like many of the high noise events are associated with a broadband noise increase from ~50-140 kHz, rather than some specific lines. Don't know if this is characteristic of all of the noisy times though.
* this 'comb' had several peaks, but seem not be precise harmonics of each other: (f3 - 3*f1)/f3 ~ 0.1%
** I think we never optimized this after changing the ERA-5 this summer, so we'd better do it next.
I wonder if the variable bump around 100 kHz can be something about the NPRO and if the bump we see is the closed loop response due to the Noise Eater.
This plot (from the Mephisto manual) shows the effect of the NE on the RIN, but not the frequency noise. I assume its similar since the laser frequency noise above 10 kHz probably just comes from the pump diode noise.
I went out to the PSL and turned off the NE at ~4:53 PM local time today to see what happened. Although the overall PCDRIVE signal looks more ratty, there is no difference in the spectra of ON/OFF when the PCDRIVE is low. When its noisy, I see a tiny peak around 1 MHz with NE OFF. Turned it back on after a few hours.
For tuning the phase and amplitude of the mod. drive:
- since we don't have access to both RF phases, I just maximized the gain using the RF phase slider. First, I flipped the sign using the 'phase flip' button so that we would be near the linear range of the slider. Then I put the servo close to oscillation and adjusted the phase to maximize the height of the ~13 kHz body mode. For the amplitude, I just cranked the modulation depth until it started to show up as a reduction in the transmission by ~0.2%, then reduced it by a factor of ~3. That makes it ~5x larger than before.
* PMC + MC were unlocked when I came in.
* I fiddled around some more with the mcup/down scripts to make locking snappier. The locking was breaking the PMC lock often, so I re-enabled the MC servo board output limiter during acquisition. It is disabled in the MC UP script.
* Re-measured the MC OLG. Still OK.
* Measured the PZT / EOM crossover (aka the FAST / PC crossover) using the connectors on Koji's summing box. With the FAST gain at 18 dB, the crossover is ~10 kHz. Looks way to shallow. Plots to follow.
* I finally discovered today that the PMC PZT stroke is what's causing the main mis-alignment of the beam going to the IMC. By relocking at a few positions, I could see that the IOO QPDs have steps when the PMC relocks. So the IO beam wander is NOT due to temperature effects on the optics mounts of the PSL table. I wonder if we have a large amount of length to angle coupling or if this is the same as the OMC PZTs ?
P.S. I found that someone is using a temporary bench power supply to power the summing box between the TTFSS and the Thorlabs HV driver...whoever did this has ~48 hours to hook up the power in the right way or else Koji is going to find out and lose it and then you have to wear the Mickey Mouse hat.
The first attachment shows the OLG measurements with 2 different values of the fast gain (our nominal FG is 18 dB). You can see that the higher gains produce some crossover instability; when tuning the gain we notice this as an increase in the PCDRIVE rms channel.
The second attachment shows the measurement of the 'crossover'. Its really just the direct measurement of the IN1 / IN2 from the FAST summing box, so its the crossover measurement where the OLG is high.
A few things that I have neglected to ELOG yet:
scripts/offsets/LSCoffsets is a new script that uses ezcaservo to set FM offsets of our LSC PDs. It still warns about large changes, and lets you revert. It reads the FM gain to pick the right gain for the ezcaservo call.
We never, ever want to use ezcaservo to do this. IN fact, we twice have already deleted scripts where people have implemented these (sometimes) unstable servos. Also, since this change had never been committed to the SVN, I just deleted it and updated from the SVN to get back the script that doesn't use any servos.
I'm going to periodically delete locking scripts that are not committed to the SVN since anyone who is too lazy to use the SVN probably can't write code worth using.
The attached PDF shows the Mathematica notebook and the associated block diagram.
In the notebook, I have written the single hop connection gains into the K matrix. P is the optical plant, C is the Common electronic gain, F is the 'fast' NPRO PZT path, and M is the phase Modulator.
G is the closed loop gain matrix. The notation is similar to matlab SS systems; the first index is the row and the second index is the column. If you want to find the TF from node 2 to node 3, you would ask for G[[3,2]].
As examples, I've shown how to get the FAST gain TF that I recently made with the Koji filter box as well as the usual OLG measurement that we make from the MC servo board front panel.
Why AS55/(TRX + TRY) instead of just TRX? Isn't (TRX+TRY) controlled by CARM?
(question is secretly from Kiwamu)
This is good news. It means that the driver probably won't limit the response of the loop - I expect we'll get 20-30 deg of phase lag @ 100 kHz just because of the acoustic response of the AOM PZT + crystal.
Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.
This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 .
This seems untenable . We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.
No elog response from outside and no elogd process on nodus, so I restarted it using 'start-elog.csh'.
The nonlinearity in the LSC detection chain (cf T050268) comes from the photodetector and not the demod board. The demod board has low pass or band pass filters which Suresh installed a long time ago (we should check out what's in REFL33 demod board).
Inside the photodetector the nonlinearity comes about because of photodiode bias modulation (aka the Grote effect) and slew rate limited distortion in the MAX4107 preamp.
With the Y Arm locked, we checked that we indeed can get loop decoupling using this technique.
The guess filter that we plugged in is a complex pole pair at 1 Hz. We guessed that the DC gain should be ~4.5 nm count. We then converted this number into Hz and then into deg(?) using some of Jenne's secret numbers. Then after measuring, we had to increase this number by 14.3 dB to an overall filter module gain of +9.3.
The RED trace is the usual 'open loop gain' measurement we make, but this time just on the LSC-MC path (which is the POY11_I -> ETMY path).
The BLUE trace is the TF between the ALS-Y phase tracker output and the FF cancellation signal. We want this to be equal ideally.
The GREEN trace is after the summing point of the ALS and the FF. So this would go to zero when the cancellation is perfect.
So, not bad for a first try. Looks like its good at DC and worse near the red loop UGF. It doesn't change much if I turn off the ALS loop (which I was running with ~10-15x lower than nominal gain just to keep it out of the picture). We need Jenne to think about the loop algebra a little more and give us our next filter shape iteration and then we should be good.
The filters were already in the damping loops but missing the MC WFS path. I checked that these accurately cover the peaks at 16.5 Hz and 23.90 and 24.06 Hz.