Yes, of course. But so far I am trusting that the coils are inheretly balanced.
Probably you are talking about the dependence of the nodal position on the frequency...I need to check if 18Hz is sufficiently high or not for 0.1mm precision.
Also I am practicing myself to understand how I can adjust them by which screws as we probably have to do this adjustement many times.
(i.e. removal of the MZ, move of the table, PSL renewal and so on)
For the actuator calibration, we may be able to calibrate actuator responses by shaking them one by one while reading the OPLEV P/Y signals.
Oh, but it gets even better: in order to trust the A2L script in this regard you have to know that the coil driver - coil - magnet gain is the same for each channel. Which you can't.
But we have these handy f2pRatio scripts that Vuk and Dan Busby worked on. They use the optical levers to balance the actuators at high frequency so that the A2L gives you a true spot readout.
But wait! We have 4 coils and the optical lever only gives us 2 signal readouts...
18 (9 pairs) Coil Drivers have been modified. Namely ETMX/ITMX/ITMY/BS/PRM/SRM/MC1/MC2/MC3.
ETMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100624 ETMX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100631
ITMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100620 IMTX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100633
ITMY Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100623 ITMY Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100632
BS Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100625 BS Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100649
PRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100627 PRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100650
SRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100626 SRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100648
MC1 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100628 MC1 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100651
MC2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100629 MC2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100652
MC3 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100630 MC3 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100653
Will be updating this linking each coil driver to the DCC
The DCC has been updated, along with the modified schematic. Links have been attached.
Per Gautam's request, I've checked the coil resistances and inductances.
A DSUB25 breakout was directly connected to the flange (Attachment 1).
The impedance meter was nulled every time the measurement range and type (R or L) were changed.
Feedthru connector: PRM1
Pin1 - flange: R = 0.8Ω
Pin11-23 / R = 1.79Ω / L=3.21mH
Pin 7-19 / R = 1.82Ω / L=3.22mH
Pin 3-15 / R = 1.71Ω / L=3.20mH
Feedthru connector: BS1
Pin1 - flange: R = 0.5Ω
Pin11-23 / R = 1.78Ω / L=3.26mH
Pin 7-19 / R = 1.63Ω / L=3.30mH
Pin 3-15 / R = 1.61Ω / L=3.29mH
Feedthru connector: SRM1
Pin1 - flange: R = 0.5Ω
Pin11-24 / R = 18.1Ω / L=3.22mH
Pin 7-20 / R = 18.8Ω / L=3.25mH
Pin 3-16 / R = 20.3Ω / L=3.25mH
Feedthru connector: PRM2
Pin1 - flange: R = 0.6Ω
Pin11-23 / R = 1.82Ω / L=3.20mH
Pin 7-19 / R = 1.53Ω / L=3.20mH
Pin 3-15 / R = N/A
Feedthru connector: BS2
Pin1 - flange: R = 0.6Ω
Pin11-23 / R = 1.46Ω / L=3.27mH
Pin 7-19 / R = 1.54Ω / L=3.24mH
Pin 3-15 / R = N/A
Feedthru connector: SRM2
Pin1 - flange: R = 0.7Ω
Pin11-24 / R = N/A
Pin 7-20 / R = 18.5Ω / L=3.21mH
Pin 3-16 / R = 19.1Ω / L=3.25mH
The SRM pinouts seem mirrored compared to the others. In fact, these two connectors are equipped with mirror cables (although they are unshielded ribbons) (Attachment 2).
The SRM sus is located on the ITMY table. There is a long in vacuum DSUB25 cable between the ITMY and BS tables. I suspect that the cable mirrors the pinout and this needs to be corrected by the in-air mirror cables.
I went around the lab and did not find any other suspensions which have the mirror cable.
WIth the BHD configuration, we will move the feedthru for the SRM to the one on the ITMY chamber. So I believe the situation is going to be improved.
For consistency, today, I measured both the BS and PRM actuator balancing using the same technique and don't find as serious an imbalance for the BS as in the PRM case. The Oplev laser source is common for both BS and PRM, but the QPDs are of course distinct.
BTW, I thought the expected resistance of the coil windings of the OSEM is ~13 ohms, while the BS/PRM OSEMs report ~1-2 ohms. Is this okay?
ugh. sounds bad - maybe a short. I suggest measuring the inductance; thats usually a clearer measurement of coil health
I didn't repeat Koji's measurement, but he reports the expected ~3.2mH per coil on all the BS and PRM coils.
So it would seem that there is some other noise which has a 1/f^2 shape and is at the same level we expected the DAC noise to be at. Rana suggested checking coherence with MC transmission to see if this could be laser intensity noise.
I also want to re-do the actuator calibrations for the vertex optics again before re-posting the revised noise budget.
I downloaded a segment of data from the time when the DRMI was locked with the BS and ITM coil driver de-whitening switched on, and looked at coherence between MC transmission and the MICH error signal. Attachment #1 doesn't show any broadband high coherence between 60-300Hz, so it cannot explain the noise in the full range between 60-300Hz.
The DQ channel for the MC transmission is recorded at 1024 kHz, so to calculate the coherence, I had to decimate the 16K MICH data.
Since we have the AOM installed, I suppose we can actually measure the intensity noise coupling to MICH by driving a line in the AOM.
I also checked for coherence in the 60-300Hz band between MICH/PRCL and MICH/SRCL, and didn't see any appreciable coherence. Need to think about this more.
Rana suggested checking coherence with MC transmission to see if this could be laser intensity noise.
The absence of evidence is not evidence of absence.
This measurement has been troublesome - I was plagued by large 60Hz harmonics (see Attachment #1), the cause of which was unknown. I powered all electronics used in the measurement set up from the same power strip (one of the new surge-protecting ones Steve recently acquired for us), but these remained present. Yesterday, Koji helped me troubleshoot this issue. We did the various things, I try to put them here in the order we did them:
Today, I tried to repeat the measurement, with the newly made twisted ribbon cable, but the large 60Hz harmonics were back. Then I realized we had also disconnected the WiFi extender and GPIB box yesterday.
Turns out that connecting the Prologix box to the SR785 (even with no power) is the culprit! Disconnecting the Prologix box makes these harmonics go away. I was using the box labelled "Santuzza.martian" (192.168.113.109), but I double-checked with the box labelled "vanna.martian" (192.168.113.105, also a different DC power supply adapter for the box), the effect is the same. I checked various combinations like
but it looks like connecting the GPIB box to the analyzer is what causes the problem. This was reproducible on both SR785s in the lab. So to make this measurement, I had to do things the painful way - acquire the spectrum by manually pushing buttons with the GPIB box disconnected, then re-connect the box and download the data using SRmeasure --getdata. I don't fully understand what is going on, especially since if the input connector is directly terminated using a 50ohm BNC terminator, there are no harmonics, regardless of whether the GPIB box is connected or not. But it is worth keeping this problem in mind for future low-noise measurements. My elog searches did not reveal past reports of similar problems, has anyone seen something like this before?
It also looks like my previous measurement of the de-whitening board noises was plagued by the same problem (I took all those spectra with the GPIB boxes connected). I will repeat this measurement.
At the meeting this week, it was decided that
I also think it would be a good idea to up the 100-ohm resistors in the bias path on the ITM coil driver boards to 1kohm wire-wound. Since the dominant noise on the coil-driver boards is from the voltage noise of the Op-Amps in the bias path, this would definitely be an improvement. Looking at the current values of the bias MEDM sliders, a 10x increase in the resistance for ITMX will not be possible (the yaw bias is ~-1.5V), but perhaps we can go for a 4x increase?
The plan is to then re-install the boards, and see if we can
We can then take a call on how much to up the series resistance in the DAC signal path.
Now that I have figured out the cause of the harmonics, I will also try and measure the combined electronics noise of de-whitening board + coil driver board and compare it to the model.
I've given Steve a list of the thin-film resistors we need to implement the changes discussed in the preceeding elogs - but I figured it would be good to see if we can realize the projected improvement in MICH displacement noise just by fixing the BS Oplev loop shape and turning the existing whitening on. Before re-installing them however, I did make a few changes:
Photos of all the boards were taken prior to re-installation, and have been uploaded to the 40m Google Photos page - I will update schematics + photos on the DCC page once other planned changes are implemented.
I also measured the transfer functions on the de-whitened signal paths on all the boards before re-installing them. I then fit everything using LISO, and updated the filter banks in Foton to match these measurements - the original filters were copied over from FM9 and FM10 to FM7 and FM8. The new filters are appended with the suffix "_0517", and live in FM9 and FM10 of the coil output filter banks. The measured TFs (for ITMs and BS) are summarized in Attachment #1, while Attachment #2 contains the data and LISO file used to do the fits (path to the .bod files in the .fil file will have to be changed appropriately). I used 2 complex pole pairs at ~10 Hz, two complex zero pairs at ~100Hz, real poles at ~15Hz and ~3kHz, and real zeros at ~100Hz and ~550Hz for the fits. The fits line up well with the measured data, and are close enough to the "expected" values (as calculated from component values) to be explained by tolerances on the installed components - I omit the plots here.
After re-installing the boards in the Eurocrate, restoring rough alignment, and updating the filter banks with the most recent measured values, I wanted to see if I could turn the whitening on for one of the optics (ITMY) smoothly before trying to do so in the full DRMI - switching off the "SimDW_0517" filter (FM9) should switch the signal path on the de-whitening board from bypass to de-whitened, and I had confirmed last week with an extender board that the voltage at the appropriate backplane connector pin does change as expected when the FM9 MEDM button is toggled (for both ITMs, BS and SRM). But today I was not able to engage this transition smoothly, the optic seems to be getting kicked around when I engage the whitening. I will need to investigate this further.
Unrelated to this work: the ETMY Oplev HeNe is dead (see Attachment #3). I thought we had just replaced this laser a couple of months ago - what is the expected lifetime of these? Perhaps the power supply at the Y-end is wonky and somehow damaging the HeNe heads?
I think the reason I am unable to engage the de-whitening is that the OL loop is injecting a ton of control noise - see Attachment #1. With the OL loop off (i.e. just local damping loops engaged for the ITMs), the RMS control signal at 100Hz is ~6 orders of magnitude (!) lower than with the OL loop on. So turning on the whitening was just railing the DAC I guess (since the whitening has something like 60dB gain at 100Hz).
The Oplev loops for the ITMs use an "Ellip15" low-pass filter to do the roll-off (2nd order Elliptic low pass filter with 15dB stopband atten and 2dB ripple). I confirmed that if I disable the OL loops, I was able to turn on the whitening for ITMY smoothly.
Now that the ETMY OL HeNe has been replaced, I restored alignment of the IFO. Both arms lock fine (I was also able to engage the ITMY Coil Driver whitening smoothly with the arm locked). However, something funny is going on with ASS - running the dither seems to inject huge offsets into the ITMY pit and yaw such that it almost immediately breaks the lock. This probably has to do with some EPICS values not being reset correctly since the recent slow-machine restarts (for instance, the c1iscaux restart caused all the LSC RFPD whitening gains to be reset to random values, I had to burt-restore the POX11 and POY11 values before I could get the arms to lock), I will have to investigate further.
GV edit 2pm 31 May: After talking to Koji at the meeting, I realized I did not specify what channel the attached spectra are for - it is C1:SUS-ITMY_ULCOIL_OUT.
But today I was not able to engage this transition smoothly, the optic seems to be getting kicked around when I engage the whitening. I will need to investigate this further.
We tried to debug the mysterious sudden failure of ASS - here is a summary of what we did tonight. These are just notes for now, so I don't forget tomorrow.
What are the problems/symptoms?
What are the (known) changes since the servos were last working?
Hypotheses plus checks (indented bullets) to test them:
For whatever reasons, it appears that dithering the cavity mirrors at frequencies with amplitudes that worked ~3 weeks ago is no longer giving us the correct error signals for dither alignment. We are out of ideas for tonight, TBC tomorrow...
In light of the discussion at today's meeting, Guantanamo and I looked at how the series resistance for the test mass coil drivers limits the amount of squeezing we could detect.
The parameters used for the following calculations are:
Since we need to operate very close to signal recycling, instead of the current signal extraction setup, we will need to change the macroscopic length of the SRC. This will change the mode matching requirements such that the current SRM does not have the correct radius of curvature. One solution is to use the spare PRM which has the correct radius of curvature but a transmissivity of 0.05 instead of 0.1. So using this spare PRM for the SRM and changing the length of the SRC to be the same as the PRC we can get
This lower transmissivity for the SRM also reduces the achievable squeezing from the current transmissivity of 0.1. For an SRM with a transmissivity of 0.15 (which is roughly the optimal) we can get
The minimum achievable squeezing moves up from around 205 Hz at 1 W to 255 Hz at 5 W because the extra power increases the radiation pressure at lower frequencies.
I've been thinking about what we need to do to the de-whitening boards for the ITMs and ETMs, in order to have low noise actuators. Noting down what I have so far, so that people can comment / point out things I've overlooked.
Attachment #1: Block diagram schematic of the de-whitened signal path on D000183 as it currently exists. I've omitted the unity gain buffer stage at the output, though this is important for noise considerations.
Some considerations, in rough order of priority:
I will experiment with a few different shapes and investigate noise and de-whitened digital signal levels based on these considerations. At the very least, I guess we should remove the x3 gain on the ETM boards, they have already been bypassed for the ITMs.
We measured the MC coil driver noise at the output monitors of the coil driver board with an SR785 in order to further diagnose the excess IMC frequency noise.
Attachments 1 and 2 show the noise for the UL coils of MC3 and MC2 with various combinations of output filters engaged. When the 28 Hz elliptic filter is on, the analog dewhitening filter is off, and vice versa. The effect of the analog low pass filter is visible in MC3, but the effect of the digital low pass filter is swamped by the DAC noise.
We locked the arms and measured the ALS beatnote in each of these filter combinations, but which filters were on did not effect the excess IMC frequency noise. This suggests that the coil drivers are not responsible for the excess noise.
Attachment 2 shows the noise for all five coils on MC1, MC2, and MC3 as well as for ITMY, which is on a different DAC card from the MCs. All filters were on for these measurements.
Why is MC2 LR so different from the others???
The previous measurements were made from the coil driver output monitors. To investigate why the MC2 LR coil has less noise than the other coils, I also measured the noise at the output to the coils.
The circuit diagram for the coil driver board is given in D010001 and a picture of the rack is on the 40m wiki here. The coil driver boards are in the upper left quadrant of the rack. The input to the board is the column of LEMOs which are the "Coil Test In" inputs on the schematic. The output monitors are the row of LEMOs to the right of the input LEMOs and are the "FP Coil Volt Mon" outputs on the schematic. The output to the coils "Coil Out" in the schematic are carried through a DB15 connector.
The attachment shows the voltage noise for the MC2 LR coil as well as the UL coil which is similar to all of the other coils measured in the previous measurement. While the LR coil is less noisy than the UL coil as measured at the output monitor, they have the same noise spectrum as measured at the output to the coils themselves. So there must be something wrong with the buffer circuit for the MC2 LR voltage monitor, but the output to the coils themselves is the same as for the other coils.
I was preparing a short write-up / test procedure for the custom HV coil driver, when I thought of something I can't resolve. I'm probably missing some really basic physics here - but why do we not account for the shot noise from DC current flowing through the series resistor? For a 4kohm resistor, the Johnson current noise is ~2pA/rtHz. This is the target we were trying to beat with our custom designed HV bias circuit. But if there is a 1 mA DC current flowing through this resistor, the shot noise of this current is 18pA/rtHz, which is ~9 times larger than the Johnson noise of the same resistor. One could question the applicability of this formula to calculate the shot noise of a DC current through a wire-wound resistor - e.g. maybe the electron transport is not really "ballistic", and so the assumption that the electrons transported through it are independent and non-interacting isn't valid. There are some modified formulae for the shot noise through a metal resistor, which evaluates to 10pA/rtHz for the same 4kohm resistor, which is still ~5x the Johnson noise.
In the case of the HV coil driver circuit, the passive filtering stage I added at the output to filter out the excess PA95 noise unwittingly helps us - the pole at ~0.7 Hz filters the shot noise (but not the Johnson noise) such that at ~10 Hz, the Johnson noise does indeed dominate the total contribution. So, for this circuit, I think we don't have to worry about some un-budgeted noise. However, I am concerned about the fast actuation path - we were all along assuming that this path would be dominated by the Johnson noise of the 4kohm series resistor. But if we need even 1mA of current to null some DC DARM drift, then we'd have the shot noise contribution become comparable, or even dominant?
I looked through the iLIGO literature, where single-stage suspensions were being used, e.g. Rana's manifesto, but I cannot find any mention of shot noise due to DC current, so probably there is a simple explanation why - but it eludes me, at least for the moment. The iLIGO coil drivers did not have a passive filter at the output of the coil driver circuit (at least, not till this work), and there isn't any feedback gain for the DARM loop at >100 Hz (where we hope to measure squeezing) to significantly squash this noise.
Attachment #1 shows schematic topologies of the iLIGO and proposed 40m configs. It may be that I have completely misunderstood the iLIGO config and what I've drawn there is wrong. Since we are mainly interested in the noise from the resistor, I've assumed everything upstream of the final op-amp is noiseless (equivalently, we assume we can sufficiently pre-filter these noises).
Attachment #2 shows the relative magnitudes of shot noise due to a DC current, and thermal noise of the series resistor, as a function of frequency, for a few representative currents, for the slow bias path assuming a 0.7Hz corner from the 4kohm/3uF RC filter at the output of the PA95.
Some lit review suggests that it's actually pretty hard to measure shot noise in a resistor - so I'm guessing that's what it is, the mean free path of electrons is short compared to the length of the resistor such that the assumption that electrons arrive independently and randomly isn't valid. So Ohm's law dictates and that's what sets the current noise. See, for example, pg 432 of Horowitz and Hill.
In the IMC actuation chain, it looks like the MC1/MC3 de-whitening boards, and also all three MC optics' coil driver boards, are showing higher noise than expected from LISO modeling. One possible candidate is thick film resistors on the coil driver boards. The plan is to debug these further by pulling the board out of the Eurocrate and investigating on the electronics bench.
Why bother? Mainly because I want to see how good the IR ALS noise is, and currently, the PSL frequency noise is causing the measurement to be worse than references taken from previous known good times.
Sometime ago, rana suggested to me that I should do this measurement more systematically.
I've now restored all the wiring at 1X6 to their state before this work.
I wanted to investigate my coil driver noise measurement technique under more controlled circumstances, so I spent yesterday setting up various configurations on a breadboard in the control room. The overall topology was as sketched in Attachment #1 of the previous elog, except for #4 below. Summary of configurations tried (series resistance was 4.5k ohm in all cases):
Attachment #1: Picture of the breadboard setup.
Attachment #2: Noise measurements (input shorted to ground) with 1 Hz linewidth from DC to 4 kHz.
Attachment #3: Noise measurements for full SR785 span.
Attachment #4: Apparent coupling due to PSRR.
Attachment #5: Comparison of low frequency noise with and without the LM6321 part of the fast DAC path implemented.
All SR785 measurements were made with input range fixed at -42dBVpk, input AC coupled and "Floating", with a Hanning window.
Today I found one of the coil driver boards, S2100619 failed the test on CH2. There appears to be an extra phase lag after 10 kHz and some resonant-like feature at 7 kHz. This of course is very high-frequency stuff and maybe we don't care about these deviations. But it could mean something is off with the channel and could potentially lead to failure in the relevant frequency band in the future. I'll need help to debug this. Please see the attachment for details of test failure.
Good catch. It turned out that the both + and - side of the output stages for CH2 were oscillating at ~600kHz. If I use a capacitance sticks to touch arbitrarily around the components, it stops their oscillation and they stay calm.
It means that the phase margin becomes small while the circuit starts up.
I decided to increase the capacitances C6 and C20 (WIMA 150pF) to 330pF (WIMA FPK2 100V) and the oscillation was tamed. 220pF didn't stop them. After visually checked the signal behavior with an oscilloscope, the unit was passed to Anchal for the TF test.
The modification was also recorded in the DCC S2100619
Koji and I had a discussion last Friday about the suspension electronics. I think there are still a few open questions - see Attachment #1. We should probably make a decision on these soon.
Other useful links:
Looking at the signals to the test mass coils, it seems borderline to me that we will be able to acquire lock and run in a low noise configuration with the same series resistor in the coil driver circuit. The way I see it, options are:
I only looked at the ETMs for this study. The assumption is that we will have no length actuation on the ITMs, only local damping and Oplev loops (and maybe some ASC actuation?), which can be sufficiently low-pass filtered such that even with coil de-whitening, we won't have any range issues.
Attachment #1 shows the time-domain traces of the coil driver signals as we transition from POX/POY lock to the ALS lock. There are some transients, but I think we will be able to hold the lock even with a 5 kohm resistor (~twice what is on ETMX right now). From just these numbers, it would seem we can even go up to 10 kohms right away and still be able to acquire lock, especially if we re-design the digital feedback loop to have better low-pass filtering of the high-frequency ALS noise, see the next attachment.
Attachment #2 shows the f-domain picture, once the arm lengths are fully under ALS control (~25 seconds onwards in Attachment #1). The RMS is dominated by high frequency ALS length loop noise, which we can possibly improve with better design of the digital control loop.
Finally, Attachment #3 shows the situation once DARM control has been transitioned over to AS55_Q. Note that the vertex DoFs are still under 3f control, so there is the possibility that we can make this even lower noise. However, one thing that is not factored in here is that we will have to de-whiten these signals to low-pass filter the DAC noise (unless there is some demonstrated clever technique with noise-mons or something to subtract the DAC noise digitally). Nevertheless, it seems like we can run safely with 5 kohms on each ETM coil and still only use ~2000 cts RMS, which is ~1/10th the DAC range (to allow for dealing with spurious transients etc).
Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).
To re-cap, every time I tried to do this in the last month or so, the optic would get kicked around. I suspected that the main cause was the insufficient low-pass filtering on the Oplev loops, which was causing the DAC rms to rail when the whitening was turned on.
I had tried some loop-tweaking by hand of the OL loops without much success last week - today I had a little more success. The existing OL loops are comprised of the following:
THe elliptic low pass was too shallow. For a first pass at loop shaping today, I checked if the resonant gain filter had any effect on the transmitted power RMS profile - turns out it had negligible effect. So I disabled this filter, replaced the elliptic low pass with a 5th order ELP with 2dB passband ripple and 80dB stopband attenuation. I also adjusted the overall loop gain to have an upper UGF for the OL loops around 2Hz. Looking at the spectrum of one coil output in this configuration (ITMY UL), I determined that the DAC rms was no longer in danger of railing.
However, I was still unable to smoothly engage the de-whitening. The optic again kept getting kicked around each time I tried. So I tried engaging the de-whitening on the ITM with just the local damping loop on, but with the arm locked. This transition was successful, but not smooth. Looking at the transmon spot on the camera, every time I engage the whitening, the spot gets a sizeable kick (I will post a video shortly). In my ~10 trials this afternoon, the arm is able to stay locked when turning the whitening on, but always loses lock when turning the whitening off.
The issue here is certainly not the DAC rms railing. I had a brief discussion with Gabriele just now about this, and he suggested checking for some electronic voltage offset between the two paths (de-whitening engaged and bypassed). I also wonder if this has something to do with some latency between the actual analog switching of paths (done by a slow machine) and the fast computation by the real time model? To be investigated.
GV 170628 11pm: I guess this isn't a viable explanation as the de-whitening switching is handled by the one of the BIO cards which is also handled by the fast FEs, so there isn't any question of latency.
With the Oplev loops disengaged, the initial kick given to the optic when engaging the whitening settles down in about a second. Once the ITM was stable again, I was able to turn on both Oplev loops without any problems. I did not investigate the new Oplev loop shape in detail, but compared to the original loop shape, there wasn't a significant difference in the TRY spectrum in this configuration (plot to follow). This remains to be done in a systematic manner.
Plots to support all of this to follow later in the evening.
Attachment #1: Video of ETMY transmission CCD while engaging whitening. I confirmed that this "glitch" happens while engaging the whitening on the UL channel. This is reminiscent of the Satellite Box glitches seen recently. In that case, the problem was resolved by replacing the high-current buffer in the offending channel. Perhaps something similar is the problem here?
Attachment #2: Summary of the ITMY UL coil output spectra under various conditions.
Our design kits are full again. They are waiting for a new brilliant PD design.
To obtain a colored version with good contrast of the grayscale image of scattering of light by dust particles on the surface of test mass, got using GigE camera. The original and colored images are attached here.
I want to make changes to c1rfm. Found uncommited changes to it from Sept 27. Since we recompiled it since then it should be safe to commit them, so I did. See svn log for details.
I used a Eurocard extension board to peek at the inputs and outputs of each of the gain-ladder AD829s on input B of the CM board in the +31dB configuration with the input terminated. (i.e with the following stages active in this order: +16dB, +8dB, +4dB, +2dB, +1dB).
The voltages I observed imply that the +8dB stage has an input voltage offset of -2mV, whereas all the other positive gain stages show around +-0.5mV. This could explain the shift observed at the +15->+16 transition. (However, since both input channels show a jump here, maybe its something more systemic about the board...)
In any case, it should be simple enough to swap out a new AD829 in place of U9B and see if it improves things, before getting too deep into the muck. (In principle, the AD829 has offset nulling pins, but I'm not sure how to do it in a non-hacky way since the board doesn't have any pads for it.)
I replaced some of the AD829s with other AD829s, but the offset situation didn't improve.
However, I figured that we don't really need the ~100MHZ bandwidth of the AD829, since the IMC loop limits us to a ~10kHz CARM bandwidth. Also, since we don't routinely use IN2 for anything, I felt free to try something else.
Specifically, I replaced all of the positive gain AD829s in the input 2 gain ladder with OP27s (U8B->U12B on D1500308), which should have input offset voltages ~30x lower than the AD829s.
Here is a comparison of the outputs these configurations perform, normalized to the output at the +0dB gain setting - where all of the op amps in the gain ladder are bypassed.
So, most of the transitions now result in an output offset change of less than 0.5mV, which is nice.
The exception seems to be where the +8dB stage is switched in or out. I may try replacing this one, as these transitions cause a lock loss now when trying to lock the arm with high bandwidth using POY.
I realized I totally forgot to post this last week, but I prototyped the comparator and boost triggering portion of the ISS, at least in part. Below is a schematic that shows the prototype circuit I made. Note that it includes ports for the oscilloscope channels that appear in the second image included. Essentially, I was able to verify that the output from the LT1016, as it's currently constructed in the ISS schematic, would be sufficient logic to switch the MAX333a.
Below, we can first see that the comparator is switching its output as desired. When the DC level of the input drops below a certain threshold (~1.6 V) the output of the comparator switches on to ~4 V. When the DC level of the input goes back up above the upper threshold (~3.2 V), the comparator switches off to ~0.3 V. The exact values of the threshold voltages can be determined/tuned at a later date, but this is the basic behavior that the comparator circuit will have.
To detect whether or not the MAX333a was switching properly, I connected the common terminal of one of the switches to a +5 V supply, and looked at the voltage coming off both the 'open' and 'closed' terminals of said SPDT switch. We can see that with Logic 0 (comparator output ~0.3 V) Channel 4 exhibits a ~5 V signal, just as we would expect from the above schematic. With Logic 1 (comparator output ~4 V), Channel 3 exhibits the characteristic 5 V signal.
Comparison between Hamamatsu S3399 and Perkin Elmer FFD-100
These are the candidates for the BB PD for the green beat detection as well as aLIGO BB PD for 532nm/1064nm.
FFD-100 seems the good candidate.
Basic difference between S3399 and FFD-100
- S3399 Si PIN diode: 3mm dia., max bias = 30V, Cd=20pF
- FFD-100 Si PIN diode: 2.5mm dia., max bias = 100V, Cd=7pF
The circuit at the page 1 was used for the amplifier.
- FFD-100 showed 5dB (= x1.8) larger responsivity for 1064nm compared with S3399. (Plot not shown. Confirmed on the analyzer.)
- -3dB BW: S3399 180MHz, FFD-100 250MHz for 100V_bias. For 30V bias, they are similar.
I made some progress in modeling MICH loop.
Putting all the LSC and SUS filters together with the MICH Finesse model I constructed an OLTF model and plot it with the measurement done by Paco and Yuta in this elog (attachment 1).
There are 2 unknown numbers that I had to adjust in order to fit the model with the measurement:
1. The SUS damping loop gain (found to be ~ 2.22), which seems to vary wildly from SUS to SUS.
2. The coil driver gain (found to be 45), which I should measure.
I find coil_driver_gain*SUS_damping_filter_gain by increasing it until the SUS damping loop becomes unstable.
The coil driver gain I find by making the measurement and model overlap.
However, there is one outstanding discrepancy between the measurement and the model: Paco and Yuta measure the MICH calibration to be 1.3e9 cts/m while my model shows it to be 1.3e10 cts/m, an order of magnitude larger.
The model can be summarized with these lines of code (I assume that the product of the ADCs(DACs) and and whitening(dewhitening) filters is unity):
BS2AS55 = TFs["AS_f2"]["BS"]
PD_responsivity = 1e3*0.8 #V/W
ADC_TF = 3276.8 #cts/V
demod_gain = 6.77 #According to https://wiki-40m.ligo.caltech.edu/Electronics/LSC_demoddulators
whitening_gain = 10**(24/20) #24 dB
BS2MICH = BS2AS55*PD_responsivity*demod_gain*whitening_gain*ADC_TF
DAC_TF = 6.285e-4 #V/cts, elog 16161
coil_TF = 0.016 #Newton/Ampere per coil, elog 15846
coil_R = 20e3 #Ohm
actuation_TF = DAC_TF*coil_TF/coil_R
OLTF = (BS2MICH*MICH_ctrl_cmplx*-6*0.5 + OSEM_filters_cmplx*OSEM_TF*2.22)*coil_filters_cmplx*actuation_TF*SUS_cmplx*45
I should write down what I didn't include for completeness:
1. AA filters
2. AS55 input 60Hz comb filter
3. Violin filters
After discussing with Paco, we agreed that the discrepancy in the MICH calibration might come from the IQ mixing angle which for the IFO is not optimized, while in Finesse is set such that all the amplitude is in one quadrature.
I'm curious why the actual OLTF included the 60Hz comb...? It is undesirable to have such structure in the OLTF around the UGF as it can cause servo instability.
And if you remove them, you don't need to model them :-)
RFM reads are slow. Rolf has said it should take 2-3 microseconds per read.
c1sus is taking about 7 microseconds per read, twice as slow as Rolf's claim.
The RFM card is in the IO chassis, and is sharing the PCIe bus with 4 ADC cards, 3 DAC cards, 4 BO cards, and a BIO card. Its possible this crowded bus is causing the reads to take even longer.
Compare read times between the c1sus computer, which has its RFM card in the IO chassis, to c1ioo, which has its RFM card in the computer.
No RFM reads: 8 microseconds
3 RFM reads: 20 microseconds (~4 per read)
6 RFM reads: 32 microseconds (~4 per read)
No RFM read: 25 microseconds (bigger model)
1 RFM read: 33 microseconds (~8 per read)
3 RFM read: 45 microseconds (~7 per read)
6 RFM read: Over 62 microseconds, doesn't run.
It looks like moving the RFM card may help by about a factor of 2 in read speed, although its still not quite what Alex and Rolf claim it should be.
The c1mcs and c1ioo models have been reverted to their normal operations.
The values obtained from both analytical and finesse solution is given in the above table along with the corresponding percentage errors.finesse1.pdf
The parameters used for this calculation are listed below.
The cavity scan data obtained from Finesse is also attached here.
Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?
The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100
But inorder to find the finesse value, I just used curser to get the central frequency of each peak and by substracting one from the other I found TMS and FSR.
The resolution was 6500 Hz. Thus, it seems that this method is not actually reliable. I am trying to find the central frequency of each mode with the help of lorentzian fits. I am attaching a fit which I did today. I have plotted its residual graph also.
I am uploading 4 python scripts to the github.
1. Analytical Solution
2. Finesse model- cavity scan
3. Finesse model- fitting
4. Finesse model- residual
Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?
> The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100
Yes, I this does not give us 0.70%
(3.893408 - 3.8863685)/3.893408 *100 = 0.18%
But any way, go for the fitting.
Oopss !! I made a mistake while taking the values from my notes. Sorry.
Over the past 36 hours, I've run full-fledged FDAs on KALLO.
The transfer functions for translational drives and responses are neatly described by the attached transfer function "matrix."
1) Extend the 3x3 analysis to include tilts and rotations in a 6x6 analysis.
2) Figure out how to do the same types of tests for phase instead of displacement.
Please edit this same entry throughout the day for the shutdown elogging.
I took a screenshot of C0VAC_MONITOR.adl to ensure that all pnematic valves are in closed positions:
The status message says "All pnematic valves closed" and the latest error message is about "V7 closed, N2 < 6.50e+01".
I found out that there was no autoburt happening for c1vac channels. I created an autoBurt.req file for the vac.db file and saved one snapshot. I also added the path of this file in autoburt/.requestfilelist . Let's see if autoburting starts by that for this file as well.
With this, I think we can safely shutdown acromag chassis. Hopefully, the relays are configured such that the valves are nominally closed in absence of a control signal. After the chassis is shut down, wwe can shutdown C1VAC by:
At the 1x8 rack, the following were switched off on their respective front panels:
PTP2 & PTP3 Controller
MKS Gauge controller
PRP Gauge Controller
G2P316a & b Controllers
Serial Device Server
Powered off from back of unit:
TP2 and 3 controllers were unplugged from respective power strips (labeled C2 and C3)
C1vac and the laptop at the workstation were shut down
Manual Gate valve was closed
All steps taken have been recorded here: