This morning I've been having problems in trying to lock the X arm.
That doesn't seem to have solved the problem. The X arm can get locked but TRX slowly moves between 0.2 and 1.
The X arm is now locked with TRX stable at ~1.
I think earlier on today I was having problems with running the alignment scripts from op540. Now I'm controlling the IFO from Rosalba and I can easily and stably lock all degrees of freedom.
I needed the X arm to be locked to align the auxiliary beam of the AbsL experiment to the IFO. To further stabilize TRX I increased the loop gain from 1 to 1.5.
Now the auxiliary beam is well aligned to the IFO and the beat is going through the PRC. I'm finally ready to scan the recycling cavity.
I also changed the gain of the PRC loop from -0.1 to -0.5.
Rana noticed that recently the temperature inside the lab has been a little bit too high. That might be causing some 'unease' to the computers with the result of making them crash more often.
For the next hours I'll be paying attention to the temperature inside the lab to make sure that it doesn't go out of control and that the environment gets too cold.
I'm working on the AbsL experiment. A measurement which involved the PRC locked is running at the moment.
Please make sure of not interfering with the interferometer until it is done. Thank you.
Today the lab is perceptibly cooler.
The temperature around the corner is 73 F.
I'm done for the moement.
I realized that I need to take into account somehow the DC power from the photodiode. By now the measurement of the transmitted beat's power is affected by the total power circulating inside of the PRC and thus it depends on the cavity alignment.
I closed the laser shutter and turned down the flipping mirrors.
I'm planning to restart measuring by 2.30pm today. Till then the interferometer is available.
I'm currently running a measurement on the PRC.
Please don't interfere with the IFO until it is done. Talk with Alberto if you've been intending to work inside the lab.
Leaving for dinner. Back in ~1hr.
I left a measurement running. Please don't interfere with it till I'm back. Thanks.
I finished measuring the AbsL for this morning. The IFO is again available.
Please don't mess up with the interferometer though. I'll be back in a couple of ours
At the moment I'm running a measurement on the PRC and I'm planning to leave it going for the time we'll be at the 40m meeting.
Please be careful in the lab. Thank you.
Thi afternoon I found that the RFM network in trouble. The frontends sync counters had railed to 16384 counts and some of the computers were not responding. I went for a bootfest, but before I rebooted c1dcu epics. I did it twice. Eventually it worked and I could get the frontends back to green.
Although trying to burtrestore to snapshots taken at any time after last wednesday till today would make the RFM crash again. Weird.
Also, c1iscey seems in a coma and doesn't want to come back. Power cycling it didn't work. I don't know how to be more persuasive with it.
I started a long measurement of the PRC's transmissivity. I'm leaving the lab and I'm going to be back at about 8 tonight. Please do not disturb the interferometer. it is important that the MC and the PRC stay locked all the time.
That measurement is finished. I'm now going to start another one that will take another hour or so. I'm leaving it running for the night. If you want to work on the IFO, it should be definitely done by 11pm.
A measurement will be running for the next hour. Please be careful.
This afternoon the watchdogs stopped working: they didn't trip when the suspension positions crossed the threshold values.
I rebooted c1susaux (aka c1dscl1epics0 in the 1Y5 rack), which is the computer that runs the watchdog processes.
The reboot fixed the problem.
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.
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.
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 temporarily turned off the 166 modulation.
I just started a measuremtn that will be running for the next hour or so. Please be careful with the interferometer.
Done. IFO available
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".
Again, this morning Zach told me that the elog had crashed while he was trying to post an entry.
I just restarted it.
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 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.
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 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.
In the last two days Steve and I took some optics away from the both ETM end table.
This is because we need an enough space to set up the green locking stuff into the end table, and also need to know how much space is available.
Optics we took away are : Alberto's RF stuff, fiber stuff and some optics obviously not in used.
The picture taken after the removing is attached. Attachment1:ETMX, Attachment2:ETMY
And the pictures taken before the removing are on the wiki, so you can check how they are changed.
The PD Kiwamu removed from the Y table was TRY, which we still need.
My bad if he took that. By mistake I told him that was the one I installed on the table for the length measurement and we didn't need it anymore.
I'm going to ask Kiwamu if he can kindly put it back.
Since last Friday either the arms or the PRC can't lock.
The montors show the beam flashing on the end mirrors, but the cavity can't get locked. The error signal looks fine. I suspect a computer problem.
Also PRC can't lock. SPOB is suspiciously stuck at about -95. Although that's not a fixed number, but covering the by hand the SPOB PD on the ITMY table doesn't change the number. I check the DC output of the photodetector and it is actually seen the beam.
Suspecting computer problems started after last Thursday's IP switch, I rebooted the frame builder, c1dcuepics, c1daqctrl and all the front ends. I then burtrestored to February 1st at 1:00 am.
Before I burtrestored c1iscepics, SPOB had gone back to more typical numbers around 0, as it usually read when PRC wasn't locked.
But burtrestoring c1iscepics, return it to the -95 of earlier.
Burterestoring to other times or dates didn't solve the problems.
This is a simple representation of the schematic:
gnd# |# Cw2# |# n23# |# Lw2# |# n22# |# Rw2 # | |\ # n2- - - C2 - n3 - - - - | \ # | | | | |4106>-- n5 - Rs -- no# iinput Rd L1 L2 R24 n6- | / | |# nin - | | | | | |/ | Rload # Cd n7 R22 gnd | | | # | | | | - - - R8 - - gnd # gnd R1 gnd R7 # | |# gnd gnd# ##
I chose the values of the components in a realistic way, that is using part available from Coilcraft or Digikey.
Using LISO I simulated the Tranfer Function and the noise of the circuit.
I'm attaching the results.
I'll post the 55MHz rfpd later.
oops, forgotten the third attachment...
here it is
# Resonant RF diode front end
I read a few datasheets of the C30642GH photodiode that we're going to use for the 11 and 55 MHz. Considering the values listed for the resistance and the capacitance in what they define "typical conditions" (that is, specific values of bias voltage and DC photocurrent) I fixed Rd=25Ohms and Cd=175pF.
Then I picked the tunable components in the circuit so that we could adjust for the variability of those parameters.
Finally with LISO I simulated transfer functions and noise curves for both the 11 and the 55MHz photodiodes.
I'm attaching the results and the LISO source files.
Last night (Mar 17) I checked the PLL setup as Mott had some difficulty to get a clean lock of the PLL setting.
Now the beating signal is much cleaner and behave straight forward. I will add some numbers such as the PD DC output, RF levels, SR560 settings...
I also had noticed the progressive change of the aux NPRO alignment to the Farady.
I strongly agree about the need of a good and robust PLL.
By modifying the old PDH box (version 2008) eventually I was able to get a PLL robust enough for my purposes. At some point that wasn't good enough for me either.
I then decided to redisign it from scratch. I'm going to work on it. Also because of my other commitments, I'd need a few days/1 week for that. But I'd still like to take care of it. Is it more urgent than that?
I found the elog down and I restarted it.
Then, after few seconds it was down again. Maybe someone else was messing with it. I restarted an other 5 times and eventually it came back up.
I spent some time trying to understand how touching the metal cage inside or bending the PCB board affected the photodiode response. It turned out that there was some weak soldering of one of the inductors.
Now some pedestals, mirrors and lenses are left on the PSL table, since we are on the middle way to construct a PLL setup which employs two NPROs instead of use of PSL laser.
So Please Don't steal any of them.
Can I please get the network analyzer back?
Hartmut suggested a possible explanation for the way the electronics transfer function starts picking up at ~50MHz. He said that the 10KOhm resistance in series with the Test Input connector of the box might have some parasitic capacitance that at high frequency lowers the input impedance.
Although Hartmut also admitted that considering the high frequency at which the effect is observed, anything can be happening with the electronics inside of the box.
I upgraded the old REFL199 to the new REFL55.
To do that I had to replace the old photodiode inside, switching to a 2mm one.
Electronics and optical transfer functions, non normalized are shown in the attached plot.
The details about the modifications are contained in this dedicated wiki page (Upgrade_09 / RF System / Upgraded RF Photodiodes)
This evening we measured the noise spectrum of the reference cavity PD used in the FSS loop. From that we estimated the transimpedance and found that the PD is shot-noise limited. We also found a big AM oscillation in correspondence of the FSS modulation sideband which we later attenuated at least in part.
i just restarted the elog for the third time in the past 12 hours.
I checked the elog.log file to debug the problem. It doesn't contain eveidence of any particular cause, except for png/jpg file uploads happened last night.
I'm not sure we can blame Image Magic again because the last crash seems to be occurred just after an entry with e jpg picture was included in the body of the message. I think Image Magic is used only for previews of attachments like pdfs or ps.
Maybe we should totally disable image magic.