We were able to lock the Y-arm using Megatron and the RCG generated code, with nothing connected to c1iscey.
All relevant cables were disconnected from c1iscey and plugged into the approriate I/O ports, including the digital output. Turns out the logic for the digital output is opposite what I expected and added XOR bitwise operators in the tst.mdl model just before it went out to DO board. Once that was added, the Y arm locked within 10 seconds or so. (Compared to the previous 30 minutes trying to figure out why it wouldn't lock).
I want to try to do the measurement with the network analyzer used as local oscillator, instead of the Marconis that I'm using now. Tha could give me better noise rejection. It would also give me information about the phase.
Also I wouldn't dislike abandoning the GPIB interfaces to acquire data.
Lately I've been trying to improve the PLL for the AbsL experiment so that it could handle larger frequency steps and thus speed up the cavity scan.
The maximum frequency step that the PLL could handle withouth losing lock is given by the DC gain of the PLL. This is the product of the mixer's gain factor K [rad/V ], of the laser's calibration C [Hz/V] and of the PLL filter DC gain F(0).
I measured these quantities: K=0.226 V/rad; C=8.3e6 Hz/V and F(0)=28.7dB=21.5. The max frequency step should be Delta_f_max = 6.4MHz.
Although in reality the PLL can't handle more than a 10 KHz step. There's probably some other effect that I'm not.
I'm attaching here plots of the PLL Open Loop Gain, of the PLL filter and of a spectra of the error point measured in different circumstances.
I don't have much time to explain here how I took all those measurements. After I fix the problem, I'm going to go go through those details in an elog entry.
Does anyone have any suggestion about what, in principle, might be limiting the frequency step?
I already made sure that both cables going to the mixer (the cable with the beat signal coming from the photodiode and the cable with the LO signal coming from the Marconi) had the same length. Although ideally, for phase locking, I would still need 90 degrees of phase shift between the mixing signals, over the entire frequency range for which I do the cavity scan. By now the 90 degrees are not guaranteed.
Also, I have a boost that adds another 20 dB at DC to the PLL's filter. Although it doesn't change anything. In fact, as said above calculating the frequency step, the PLL should be able to handle 100KHz steps, as I would want the PLL to do.
I might have found the problem with the PLL that was preventing me from scanning the frequencies by 100KHz steps. A dumb flimsy soldering in the circuit was making the PLL unstable.
After I fixed that problem and also after writing a cleverer data acquisition script in Python, I was able to scan continuosly the range 10-200MHz in about 20min (versus the almost 1.5-2 hrs that I could do previously). I'm attaching the results to this entry.
The 'smears' on the right side of the resonance at ~33MHz, are due to the PSL's sideband. I think I know how to fix that.
As you can see, the problem is that the model for the cavity transmission still does not match very well the data. As a result, the error on the cavity length is too big (~> 10 cm - I'd like to have 1mm).
Anyway, that was only my first attempt of scanning. I'm going to repeat the measurement today too and see if I can come out better. If not, than I have to rethink the model I've been using to fit.
I've added the control logic for the outputs going to the Contec Digital Output board. This includes outputs from the QPD filters (2 filters per quadrant, 8 in total), as well as outputs going to the coil input sensor whitening.
At this point, the ETMY controls should have everything the end station FE normally does. I'm hoping to do some testing tomorrow afternoon with this with a fully locked IFO.
I just aligned PRM and locked PRC and I noticed that SPOB is much higehr than it used to be. It's now about 1800, vs 1200 than it used to be last week.
Isn't anyone related to that? If so, may I please know how he/she did it?
oops, my bad. I cranked the 33MHz modulation depth and forgot to put it back. The slider should go back to around 3.
I was actually hoping that the alignment got better.
Did some more test to get better performance at higher frequencies.
Increased # taps to 4000 and reduced downsampling to 4, without changing the AA32 filters, from CORR, EMPH and the matching ADPT channels. But for testing I turned off AA32 from the input PEM channels. So that high frequency still gets blocked at CORR, but the adaptive filters have access to higher frequencies. Once we fix some reasonable downsampling, we should create corresponding AA filters.
I used only two channels, RANGER/GUR2_Y and GUR1_Z, and basically they had only one filter 0.1:0
This set up gave little better performance (more reduction at more frequencies), at some point even the 16HZ peak was reduced by a factor of 3. The 24Hz peak was a bit unstable, but became stable after I removed the Notch24 filters from PEM channels, to ensure that OAF is aware of those lines. There was some improvement also at the 24Hz peak.
The 2 SOS towers for the ITMs have been assembled, and are on the flow bench in the cleanroom. Next up is to glue magnets, dumbells, guiderods and wire standoffs to the optics, then actually hang the mirrors.
I have installed a slow start throttle valve in front of V3 This spring loaded valve will cut down on the flow at high pressures. There will be no more sand storme
and static built-up during pump down.
There is lot of coherence between the error signal and PEM channels at 5-100Hz. We had been applying a 1Hz low pass filter to all the GUR and RANGER channels for stability. I turned those off and OAF still works with mu=0.0025, this will give us some more freedom. Kind of annoying for testing though, it takes about 45min to adapt!
In any case, there is no significant improvement at high frequencies as compared to our usual OAF performance. Also, the low frequency improvement (see previous e-log) is lost in this set up. I think, we have to adjust the number of taps and channels to do better at high frequencies. Also, delay can be important at these frequencies, needs some testing.
At 0.1-1.0Hz, there is some coherence between MC_L and RANGER_Y & GUR_Y, see the first figure. Also GUR_Z has low noise there. So I used all five of them, increased the gains of GUR_Z from 0.1 to 0.5. Some improvement near 0.5Hz. We possibly can not do any better with these PEM measurement, as the coherence of the adapted error signal and the PEM channels is almost zero, see the second figure. May be we need to think about placing the seismometers at different places/orientations.
However, there is lot more scope at higher frequencies, lot of coherence at 5-100Hz.
We will be moving the 131.215.113.XXX ip addresses of the martian network over to a 192.168.XXX.YYY scheme.
Computer names (i.e. linux1, scipe25/c1dcuepics) will not change. The domain name martian, will not change (i.e. linux1.martian.). What will change is the underlying IP address associated with the host names. Linux1 will no longer be 184.108.40.206 but something like 192.168.0.20. If everything is done properly, that should be it. There should be no impact or need to change anything in EPICS for example. However, if there are custom scripts with hard coded IP addresses rather than hostnames, those would need to be updated, if they exist.
Each computer and router will need to either be accessed remotely, or directly, and the configuration files controlling the IP address (and/or dns lookup locations) be modified. Then it needs to be rebooted so the configuration changes take effect. I'll be making an updated list of computers this week (tracked down via their physical ethernet cables), and next week, probably on Thursday, and then we simply go down the list one by one.
For a linux machine, this means checking the /etc/hosts file and making sure it doesn't have old information. It should look like:
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
Then change the /etc/sysconfig/network-scripts/ifcfg-eth0 file (or ethX file depending on the ethernet card in question). The IPADDR, NETWORK, and GATEWAY lines will need to be changed. You can change the hostname (although I don't plan on it) by modifying the /etc/sysconfig/network file.
The /etc/resolv.conf file will need to be updated with the new DNS server location (i.e. 220.127.116.11 to 192.168.0.20 for example).
Simlarly to linux, the /etc/hosts file will need to be updated and/or simplified. The /etc/defaultrouter file will need to be updated to the new router ip. /etc/defaultdomain will need to be updated. The /etc/resolv.conf will need to be updated with the new dns server.
Looking at the vxWorks machines, the command bootChange can be used to view or edit the IP configuration.
The following is an example from c1iscey.
'.' = clear field; '-' = go to previous field; ^D = quit
boot device : eeE0
processor number : 0
host name : linux1
file name : /cvs/cds/vw/pIII_7751/vxWorks
inet on ethernet (e) : 18.104.22.168:ffffff00
inet on backplane (b):
host inet (h) : 22.214.171.124
gateway inet (g) :
user (u) : controls
ftp password (pw) (blank = use rsh):
flags (f) : 0x0
target name (tn) : c1iscey
startup script (s) :
other (o) :
value = 0 = 0x0
By updating the the host (name of machine where its mounting /cvs/cds from - i.e. linux1), inet on ethernet (the IP of c1iscey) and host inet (linux1's ip address), we should be able to change all the vxWorks machines.
The DNS server running on linux1 will need to be updated with the new IPs and domain information. The host file on linux1 will also need to be updated for all the new IP addresses as well.
This will need to be handled carefully as the last time I tried getting away without the host file on linux1, it broke NFS mounting from other machines. However, as long as the host on linux1 is kept in sync with the dns server files everything should work.
I restarted the ELOG on NODUS just now. Our attempt to set up error logging worked - it turns out ELOG was choking on the .ps file attachment.
So for the near future: NO MORE .PS files! Use PDF - move into the 20th century at least.
matlab can directly make either PNG or PDF files for you, you can also use various other conversion tools on the web.
Of course, it would be nice if nodus could handle .ps, but its a Solaris machine and I don't feel like debugging this. Eventually, we'll give him away and make the new nodus a Linux box, but that day is not today.
The electrical shop has to connect the new power transformer at CES. This means we will have no AC power for ~8 hrs on Saturday, February 20
Is this date good for us to power down ALL equipment in the lab?
Again, this morning Zach told me that the elog had crashed while he was trying to post an entry.
I just restarted it.
I checked the situation from my home and the problem was solved.
The main problem was undefined state of the autolocker and the strange undefined switch states, being associated with the bootfest and burtrestore.
- MC UP/DOWN status shows it was up and down. So I ran scripts/MC/mcup and scripts/MC/mcdown. These cleared the MC autolocker status.
- I had a problem handling the FSS. After mcup/mcdown above, I randomly pushed the "enable/disable" buttons and others, and with some reason, it recovered the handling. Actually it acquired the lock autonomously. Kiwamu may have also been working on it at the same time???
- Then, I checked the PSL loop. I disconnected the loop by pushing the "test" button. The DC slider changes the PZT voltage only 0~+24V. This is totally strange and I started pushing the buttons randomly. As soon as I pushed the "BLANK"/"NORMAL" button, the PZT output got back under the control.
- Then I locked the PMC, MZ, and MC as usual.
Alberto: You must be careful as the modulations were restored.
It's been an iffy last few hours here at the 40m. Kiwamu, Koji and I were all sitting at our desks, and the computers / RFM network decided to crash. We brought all of the computers back, but now the RefCav and PMC don't want to lock. I'm a wee bit confused by this. Both Kiwamu and I have given it a shot, and we can each get the ref cav to sit and flash, but we can't catch it. Also, when I bring the PMC slider rail to rail, we see no change in the PMC refl camera. Since c1psl had been finicky coming back the first time, I tried soft rebooting, and then keying the crate again, but the symptoms remained the same. Also, I tried burt restoring to several different times in the last few days, to see if that helped. It didn't. I did notice that MC2 was unhappy, which was a result of the burtrestores setting the MCL filters as if the cavity were locked, so I manually ran mcdown. Also, the MC autolocker script had died, so Kiwamu brought it back to life.
Since we've spent an hour on trying to relock the PSL cavities (the descriptive word I'm going to suggest for us is persistent, not losers), we're giving up in favor of waiting for expert advice in the morning. I suppose there's something obvious that we're missing, but we haven't found it yet......
This is a (sort of) known problem with the EPICS computers: it's generally called the 'sticky slider' problem, but of course it applies to buttons as well. It happens after a reboot, when the MEDM control/readback values don't match the actual applied voltages. The solution (so far) is just to `twiddle' the problematic sliders/button. There's a script somewhere called slider_twiddle that does this, but I don't remember if it has PSL stuff in it. A better solution is probably to have an individual slider twiddle script for each target machine, and add the running of that script to the reboot ritual in the wiki.
The low PMC transmission alarm was on this morning. The PMC alignment needs a touch up.
I checked the situation from my home and the problem was solved.
Zach made me notice that the elog had crashed earlier on this afternoon.
I just restarted it with the restarting script.
Instructions on how to run the last one are now in the wiki page. Look on the "How To" section, under "How to restart the elog".
CES construction is progressing. The 40m suspensions are bearing well.
atm1, PEM vs sus plots of 120 days
atm2, big pool walls are in place, ~10 ft east of south arm
atm3, 10 ft east of ITMY
atm4, ~60 ft east of ITMY
atm5, cold weather effect of N2 evaporator tower
Joe let me use the resonant EOM for GigE phase camera for a while.
Then, I immediately started to open it :)
it uses the MiniCIrcuits T5-1T transformer and a TOKO RCL variable inductor.
The photos are on the Picasa 40m album.
Last night, I connected megatron's BO board to the analog dewhitening board. However, I was unable to lock the y arm (although once I disconnected the cable and reconnected it back the xy220 the yarm did lock).
So either A) I've got the wrong cable, or B) I've got the wrong logic being sent to the analog dewhitening filters.
During testing, I ran into an odd continuous on/off cycle on one of the side filer modules (on megatron). Turns out I had forgotten to use a ground input to the control filer bank (which allows you to both set switches as well as read them out), and it was reading a random variable. Grounding it in the model fixed the problem (after re-making).
I tried some combination of PEM channels and filters to improve OAF performance at other frequencies, where we do not have any improvement so far. There is progress, but still no success.
Here are the main things I tried:
For the ACC channels replaced the 0.1 Hz high pass filters by 3Hz high pass and turned off the 1: filter.
Then I tried to incorporate the Z ACC/GUR channels, with some reasonable combination of the others.
The Z axis Guralp and Accelerometers were making OAF unstable, so I put a 0.1 gain in all four of those.
Following the PEM noise curves Rana has put up, we should probably use
In the end I tried this combination, it was stable after I reduced the GUR_Z gain, but looked very similar to what we got before, no improvement at 5Hz or 0.5Hz. But there was a stable hint of better performance at > 40Hz.
Possibly we need to increase the GUR_Z gain (but not 1) and try to use ACC_Z channels also. Since we can not handle many channels, possibly using one GUR_Z and one ACC_Z would be worth checking.
The 2W NPRO from Valera arrived today and I haf hidden it somewere in the 40m lab!
Rana was so kind to make this entry for me
I tried downsampling value 32 (instead of 16), to see if it has any effect on OAF. Last week I encountered some stability issue - adaptation started to work, but the mode cleaner was suddenly unlocked, it could be due to some other effect too.
One point to note is that different downsampling did not have any effect on the CPU meter (I tried clicking the "RESET" button few times, but no change).
I just started a measuremtn that will be running for the next hour or so. Please be careful with the interferometer.
Done. IFO available
I temporarily turned off the 166 modulation.
This morning the LSC scripts wheren't running properly. I had to reboot c1iscey, c1iscex, c1lsc, c1asc .
I burtrestored to Monday January 25 at 12:00.
I turned the StripTool and ALARMS and BLRMS back on on op540m. Looks like it has been rebooted 5 days ago and no one turned these back on. Also, there was a bunch of junk strewn around its keyboard which I restrained myself from throwing in the trash.
The BLRMS trends should be active now.
We turned on the OAF again to make sure it works. We got it to work well with the Ranger as well as the Guralp channels. The previous problem with the ACC is that Sanjit and Matt were using the "X" channels which are aligned the "Y" arm. Another casualty of our ridiculous and nonsensical coordinate system. Long live the Right Hand Rule!!
The changes that were made are:
Other parameters which were kept at usual setting:
Screenshots are attached.
Burt snapshot is kept as: /cvs/cds/caltech/scripts/OAF/snaps/ass_burt_100126_211330.snap
taken using the script: /cvs/cds/caltech/scripts/OAF/saveOAF
we should put this in ASS screen.
ERROR Detected in filter ASS_TOP_PEM_24 (RANGER): 1: was actually typed as a 1Hz high pass filter!
(Correcting this one seems to spoil the adaptation)
Possibly this makes sense, we may not want to block witness signals in the 0.1-20 Hz range.
11:40 PM: Leaving the lab with the OAF running on 5 PEM channels (Ranger + Guralp 1&2 Y & Z). There's a terminal open on op440m which will disable the OAF in ~2.8 hours. Feel free to disable sooner if you need the MC/IFO.
You can turn the 166 off if you want. MZ is unhappy after its turned off, but that's just the thermal transient from removing the RF heat. After a several minutes, the heat goes away and the MZ can be relocked.
One of these days we should evaluate the beam distortion we get in EOMs because of the RF heat induced dn/dT. Beam steering, beam size, etc.
I turned off the modulation at 166MHZ becasue I don't need it if I'm only locking the PRC.
It was introducing extra amplitude modulations of the beam which interfered with the AbsL's PLL photodiode.
I'm going to turn it back on later on.
I turned back on the 166MHz modulation just a bit. I set the slider at 4.156.
When it was totally off the MZ seemd quite unhappy.
I was talking with Vladimir on Friday discussing the Binary Output board, we looked at the manual for it (Contec DO-32L-PE) and we realized its an opto-coupler isolated open-collector output. He mentioned they had the right kind of 50 channel breakout board for testing in Riccardo's lab.
This morning I borrowed the 50 channel breakout board from Riccardo's lab, and along with some resistor loads, test the BO board. It seems to be working, and I can control the output channel on/off state.
I'm leaving a measurement running overnight. It should be done in about one hour.
Tomorrow morning, If you need to use the interferometer, and you don't want to have the auxiliary beam going onto the dark port, you can turn down the flipping mirror and close the NPRO's mechanical shutter.
This is what I measured last night:
This is not a fit. It's just a comparison of the model with the data.
Turns out the CDSO32 part (representing the Contec BO-32L-PE binary output) rquires two inputs. One for the first 16 bits, and one for the second set of 16 bits. So Alex added another input to the part in the library. Its still a bit strange, as it seems the In1 represents the second set of 16 bits, and the In2 represents the first set of 16 bits.
I added two sliders on the CustomAdls/C1TST_ETMY.adl control screen (upper left), along with a bit readout display, which shows the bitwise and of the two slider channels. For the moment, I still can't see any output voltage on any of the DO pins, no matter what output I set.
In order to see the Contec DO-32L-PE Digital output PCIe card with the new controls, we had to add the CDO32 part to the CDS_PARTS.mdl file in control /cds/advLigo/src/epics/simLink/ directory on megatron, as well as create the actual model mdl file (based on cdsDio.mdl) in the control/cds/advLigo/src/epics/simLink/lib directory.
The CDO32.pm file (in /home/controls/cds/advLigo/src/epics/util/lib) has existed for some time, it was just missing the associated pieces in simlink. However, Alex also checked out a newer version Dio.pm in the process. As we are not using this part at this time, it should be fine.
The code now compiles and sees the digital output card.
You need a special care on this block as it turned out that the code does not compiled if the "constant" block is connected to the input. You must use appropriate block such as bitwise operator, as shown below.
Now the lock with megatron is pretty easy. Really. It's very cool.
As we saw the oscillation of the YARM servo, we temporalily increased the gain of TRY filter by a factor of 2 (0.003->0.006). Also decreased the gain of YARM servo by the factor of 2 (1->0.5). This makes the servo gain reduced by a factor of 4 in total. This change seemed to come from the change of the ADC/DAC range.
We finally fixed the hi-gain pd transmission communications from Megatron to the c1lsc by tracking down the correct RFM memory location (which is unhelpfully labeled as a qpd channel in both losLinux and lsc40.m). The memory location is 0x11a1e0, and is refered to as qpdData.
This morning I and Steve replaced the dry fore pump of TP3, which is located under the y-arm.
After replacing it we confirmed vacuum normal condition. The fore line pressure of TP3 went down to 11 mTorr from 750 mTorr
Attached picture is new pump after setup.
Nice and interesting plot.
I suppose slight decrease of the Schnupp asymmetry (in your model) adjusts the discrepancy in the high freq region.
At the same time, it will make the resonance narrower. So you need to put some loss at the recombination (=on the BS)?
...of course these depends on the flatness of the calibration.
I made a wiki page dedicated for the photos of the optical tables.
The current layouts were uploaded.
5. For the impedance matching, I will select a transformer so that 55MHz is matched. In contrast I will leave two lower resonances as they are.
This is because 11MHz and 29.5MHz usually tend to have higher impedance than 55MHz. In this case, even if the impedance is mismatched, the gain for these can be kept higher than 11.
I will post the detail for this mismatched case tomorrow.
Here the technique of the impedance matching for the triple resonant circuit are explained.
In our case, the transformer should be chosen so that the impedance of the resonance at 55MHz is matched.
We are going to use the transformer to step up the voltage applied onto the EOM.
To obtain the maximum step-up-gain, it is better to think about the behavior of the transformer.
When using the transformer there are two different cases practically. And each case requires different optimization technique. This is the key point.
By considering these two cases, we can finally select the most appropriate transformer and obtain the maximum gain.
( how to maximize the gain ?)
Let us consider about the transformer. The gain of the circuit by using the transformer is represented by
Where ZL is the impedance of the load (i.e. impedance of the circuit without the transformer ) and n is the turn ratio.
It is apparent that G is the function of two parameters, ZL and n. This leads to two different solutions for maximizing the gain practically.
- case.1 : The turn ratio n is fixed.
In this case, the tunable parameter is the impedance ZL. The gain as a function of ZL is shown in the left figure above.
In order to maximize the gain, Z must be as high as possible. The gain G get close to 2n when the impedance ZL goes to infinity.
There also is another important thing; If the impedance ZL is bigger than the matched impedance (i.e. ZL = 50 * n^2 ), the gain can get higher than n.
- case.2 : The impedance ZL is fixed.
In contrast to case1, once the impedance ZL is fixed, the tunable parameter is n. The gain as a function of n is shown in the right figure above.
In this case the impedance matched condition is the best solution, where ZL=50*n^2. ( indicated as red arrow in the figure )
The gain can not go higher than n somehow. This is clearly different from case1.
( Application to the triple resonant circuit )
Here we can define the goal as "all three resonances have gain of more than n, while n is set to be as high as possible"
According to consideration of case1, if each resonance has an impedance of greater than 50*n^2 (matched condition) it looks fine, but not enough in fact.
For example if we choose n=2, it corresponds to the matched impedance of 50*n^2 = 200 Ohm. Typically every three resonance has several kOhm which is clearly bigger than the matched impedance successfully.
However no matter how big impedance we try to make, the gains can not be greater than G=2n=4 for all the three resonance. This is ridiculous.
What we have to do is to choose n so that it matches the impedance of the resonance which has the smallest impedance.
In our case, usually the resonance at 55MHz tends to have the smallest impedance in those three. According to this if we choose n correctly, the other two is mismatched.
However they can still have the gain of more than n, because their impedance is bigger than the matching impedance. This can be easily understand by recalling the case1.
(expected optimum gain of designed circuit)
By using the equation (1), the expected gain of the triple resonant circuit including the losses is calculated. The parameters can be found in last entry.
The turn ratio is set as n=11, which matches the impedance of the resonance at 55MHz. Therefore 55MHz has the gain of 11.
The gain at 11MHz is bigger than n=11, this corresponds to the case1. Thus the impedance at 11MHz can go close to gain of 22, if we can make the impedance much big.