The MCL path of MC2 was in a strange state as the filters were activated as if it is in lock even though we had no lock. So I manually ran "mcdown". This reset the filters of the MCL path.

Since it wasn't sure whether all the front-ends had been restored after the bootfest, I burtrestored everything to Dec 26 at 20:00.

Always keep in mind that to burtrestore c1dcuepics, the snapshot file has to be modified by hand by moving the last quote up to the line before the last.

I opened the auxiliary laser's shutter.

I'm currently working on the AP table.

 I finished working on the table.

I closed the AUX NPRO's shutter.

The HIGH and LOW channels are added into the burt request file "/target/c1losepics/autoBurt.req".

These values are used to colorize the alarm texts in the "C1DRIFT_MONITOR.adl" like a threshold. (the screenshot attached)

Hereafter these values will be automatically restored by the burt.  Happy !

We have installed the new Video Matrix.

Its still in an intermediate state, so don't try to "fix" anything before Kiwamu and I get back onto it in the afternoon.

The status so far is that we have removed the old switch (it was a 256 input x 128 output !! mux)  and installed the new one in the same rack. We have hooked it up to the CDS network and have set up its matrix by using the web interface (i.e. NOT EPICS).

Along the way, we discovered that there is lack of impedance matching in the video all over the 40m. Video signals are RF and need to be treated that way. The PSL signals are T'd around and sent on 50 Ohm cables to high impedance monitor inputs.

We should eliminate any switches besides the new one (called Luciana) and control the PSL's Video Monitor from the main MUX interface. No more Rogue Video Switches.

Another couple of things we have found is about RCR camera.

(1) The long cable which connects the RCR camera box and the video matrix doesn't work. Although the signal is alive and we can see it by the local tv monitor nearby PSL.

(1) The reflected beam going to the camera is too weak to see in the monitor.  We found a strange polarized cube splitter in front of the camera. We should modify it sooner or later.

Before we installed the video switch box, we also took some photos of it. We uploaded them onto the 40m Picasa.

Video Matrix

The first photo is the an entire view of the switch box. The following four photos are the details of the switch matrix.

 The slideshow below is a dump of the last several months of photos from the Olympus. The originals have been deleted.

I added 600 cc of Arrowhead Distilled Water to the chiller.

60 days plot shows that about every ~ 10 days I have to add some.

Please check the water level yourself.

This morning I found all the watchdogs had tripped during the night.

I restored them all.

I can't damp ITMX. I noticed that its driving matrix is all 1s and -1s as the the right values had been lost in some previous burtrestoring.

Rana fixed the problem. He found that the side damping was saturating. He lowered the gain a little for a while, waited for the the damping to slow down the optic and then he brought the gain back where it was.

He also upadted the MEDM screen snapshot.

The input channels of the cameras and the output channels for the monitors are summarized on the wiki.

The channel table on the wiki is very helpful when you want to make a change in the video matrix.

thank you.

The most up-to-date T and R plots for the Y1 and Y1S mirrors, as well as a T measurement for the ETM, can be found on:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/Optics/RTmeasurement

Using the techniques employed at LLO, and then by Rana here at the 40m a few weeks ago, Wiener filters have been installed on the inputs of all of the PEM IIR channels which are hooked up to the 110B PEM ADCU.  Some slight modifications have taken place to the code, and it's all been checked in to the 40m svn. 

I have installed the filters into:  All 6 Wilcoxon accelerometers, the Ranger seismometer, and one of the Guralps (GUR1).  The other Guralp is currently connected through the ASS/OAF machine's ADC, so it's not used in this test. The filters are all labeled "Wiener", and are FM1 in the C1:ASS-TOP_PEMIIR_## filter banks.

The first figure below is the output of the Wiener Filter calculation program.  It shows the uncorrected MC_L (black) and the corrected MC_L (red), using the optimal wiener filter.  This is as good as we should be able to do with these sensors in these positions.

The second figure is a DTT shot of me trying out the nifty new filters.  They seem to maybe do a teensy bit on the microseism, but otherwise it's a bit unremarkable.  Hopefully I'll get better subtraction during the day, when the base level for MC_L is higher.  Here, Black is uncorrected MC_L, Red is the corrected MC_L, Blue is the actuation channel, and green is an example seismometer channel to illustrate the ground motion at the time.

For posterity, since it's not all in one elog that I can find, the order of operations to install a Wiener Feed Forward filter is as follows:

1.  (When you can borrow the IFO) Take a very careful TF of the plant, between your actuation point and your error signal readout.  At the 40m, this means between C1:ASS-TOP_SUS_MC1_EXC and C1:IOO-MC_L, since we actuate by pushing on the MC1 coils.  At the sites / future 40m, this would be between the HEPI (or STACIS) and the error signal.  The limit of how good your Feed Forward can do will depend heavily on how good this TF is.  Coherence should be above ~0.95 for all points.  Export this data from DTT as a .txt file, using units "Complex (abs/rad)". 

2. Run fitMC12MCL.m (or equivalent wrapper file) to fit the transfer function you just took with some Poles and Zeros.  Make sure to edit the wrapper file with your new .txt file's name so you're getting a fresh TF (if you've just taken one).

3. (Again, when you can borrow the IFO) Run getMCdata.m (or equivalent) to fetch witness channel data and error signal data.  At the 40m, this usually means C1:IOO-MC_L, and witness sensors which are around the MC chambers.  This data should be taken at a time when the cavity is locked, but pretty much on it's own. (i.e. probably shouldn't have Common Mode feedback on the MC - so the MC should be locked, but not the full IFO, for example.)

4.  Run c1winoiir.m (the main program here, which contains some of these notes). This will take in the TF data you've fit, and the witness channel data you have, and calculate the optimal combination of Wiener filters for your witness channels.  It pre-filters your witness data by your TF, then calculates the Wiener filter.  The resulting FIR filters are saved in a file.

5.  Run firfit.m  This will take the FIR Wiener filters you've just created, and convert them conveniently to IIR filters, in a format to be copied directly into Foton.  For each witness channel, you'll get the IIR filter in 2 formats:  the first is for copying into the Foton .txt file (ex ASS.txt), and the second is for copying into the Foton gui, in the "Command" box on the filter design screen.  The "o" at the end of the copy-able filter indicates to Foton that it is a Z-Plane Online filter.  Copy filters appropriately (there should be a line preceding each set of SOS filter formats to indicate which channel this Wiener filter is for...these channel names are extracted from your getMCdata.m)

6. Save your Foton file, and update your Coefficients in MEDM.  Enable your outputs to actuators, and watch magic happen!

On the To-Do list:

Check the transfer of signal btwn PEMIIR matrix and the 9x1 'matrix' that sends the signals to the SUS inputs.  In the SimuLink, the input to the 9x1 matrix is a bundle of 8 numbers (the 8 outputs of the PEMIIR matrix), but it looks like it only pays attention to the first one.  Need to figure out how to make it realize that it's a bundle, not a single number. 

Also, the OAF up / down scripts don't seem to be working on any of the control room computers.  This needs to be checked in to / fixed (but not tonight....)

EDIT 6 Jan 2010:  Shouldn't have done this.  My bad.  The AA32 is on the other PEM matrix because the Adaptive code runs at 64Hz, so there's downsampling, calculating, and upsampling which goes on.  The Feed Forward path all runs at 2kHz, the regular rate of the ASS/OAF machine.  All of these filters are turned off (although I haven't deleted them from Foton).  Since we're focusing on low frequency stuff and trying to get that to do some subtraction, we're not worrying about the junk at higher frequencies just yet.

I have put AA32 filters into the PEMIIR matrix's input filter banks (ie, C1:ASS-TOP_PEMIIR_##), to match the ones that are in the same places in the regular PEM matrix on the OAF screen. 

I redid the uncorrected vs. corrected MC_L DTT printout, shown below. You can see that there's less junk at higher frequencies in the Blue (actuation channel) trace, which is good.

All the DAQ screens are bright red.  Thumbs down to that.

 All better now. 

Last night, we installed the VMI 5565 RFM card into Megatron.  After turning off the watchdogs for the ETMY optic, we disconnected the RFM fiber, and connected it to megatron, then powered it up. 

We modified the RCG code to have 3 rfmio blocks, which were reading 0x11a1c0 (ascPit), 0x11a1c4 (ascYaw), and 0x11a1c8 (lscPos).  These were connected to the approriate filter module inputs, and we also added grounds to the front of the rfmio blocks (we looked at the ass code which was setup that way, so we just did the same thing).  When we started it however, it didn't read properly.  If we turned off the input and set and offset, it calculated the output of the filter module correctly, (i.e. just the offset value), but as soon as we turned on the input, it was set to 0, no matter the offset value, which indicated it was reading something correctly.

After this test, the RFM fibers were reconnected to c1iscey, we rebooted c1iscey, and we confirmed that the system was working properly again.  We turned the watch dogs back on for ETMY.

Alex came over with a short RFM cable this morning.  We used it to connect the rfm card in c1iscey to the rfm card megatron

Alex renamed startup.cmd in /cvs/cds/caltech/target/c1iscey/ to startup.cmd.sav, so it doesn't come up automatically.  At the end we moved it back.

Alex used the vxworks command d to look at memory locations on c1iscey.  Such as d 0xf0000000, which is the start of the rfm code location.  So to look at 0x11a1c8 (lscPos) in the rfm memory, he typed "d 0xf011a1c8".  After doing some poking around, we look at the raw tst front end code (in /home/controls/cds/advLigo/src/fe/tst), and realized it was trying to read doubles.  The old rts code uses floats, so the code was reading incorrectly.

As a quick fix, we changed the code to floats for that part.  They looked like:

etmy_lsc = filterModuleD(dsp_ptr,dspCoeff,ETMY_LSC,cdsPciModules.pci_rfm[0]? *(\
(double *)(((void *)cdsPciModules.pci_rfm[0]) + 0x11a1c8)) : 0.0,0);

And we simply changed the double to float in each case.  In addition we changed the RCG scripts locally as well (if we do a update at some point, it'll get overwritten).  The file we updated was /home/controls/cds/advLigo/src/epics/util/lib/RfmIO.pm

Line 57 and Line 84 were changed, with double replaced with float.

return "cdsPciModules.pci_rfm[0]? *((float *)(((void *)cdsPciModules.pci
_rfm[$card_num]) + $rfmAddressString)) : 0.0";

. "  *((float *)(((char *)cdsPciModules.pci_rfm[$card_nu
m]) + $rfmAddressString)) = $::fromExp[0];\n"

This fixed our ability to read the RFM card, which now can read the LSC POS channel, for example.

Unfortunately, when we were putting everything the way it was with RFM fibers and so forth, the c1iscey started to get garbage (all the RFM memory locations were reading ffff).  We eventually removed the VME board, removed the RFM card, looked at it, put the RFM card back in a different slot on the board, and returned c1iscey to the rack.  After this it started working properly.  Its possible in all the plugging and unplugging that the card somehow had become loose.

The next step is to add all the channels that need to be read into the .mdl file, as well as testing and adding the channel which need to be written.

Alex added a new module to the RCG, for generating RFMIO using floats.  This has been commited to CVS.

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.

I have assembled the circuit and the control box for the quadrant magnetic levitation yesterday. The final setup is shown

in the figure below:

Due to my carelessness, I I connected the wrong ends of the power supply. I damaged 4 op-amp and one voltage 

regulator during this assembly. This stupid mistake spent me several hours to fix, and I got a bitter lesson;-(

Afterwards, I replaced those op-amps and reconnected the power supply . Kiwamu helped me and we measured

the transfer function of this circuit.  The transfer function agrees with  the specification in the schematics which

has a integrator below 1 Hz and a differentiator from 5 to 20 Hz. The bode plot for the measured transfer function

is the following:

Today I tested the photodetector parts and found that there is a mysterious oscillation. Whenever I connect the

photodector input A of the circuit (as indicated in the figure below),

the output of the op-amp has a 500k Hz oscillation shown up in the oscilloscope.This happens even A is disconnected from

the photodetector and connected to an open end wire. I don't know how to eliminate it, and its amplitude is so large (peak to

peak is around 2.5 V) which completely dominates the photodetector output. Does anybody has some ideas? Thanks.

1. Why do all of the BNCs have no GND connection? Each should have the individual cables to the ground. Each signal line and the corresponding ground line should be twisted together.

2. This looks the (usual) oscillation of the V-I conversion stage but I can't tell anything as I don't have the circuit diagram of the whole circuit.

3. In a certain case, putting some capacitance at the feedback may help. Read P.11 of the data sheet of LT1125. Try to put some capacitors from 20pF to some larger one whether it changes the situation or not. I suppose the bandwidth of your sensor can be ~1kHz. So putting a capacitance less than 10nF still has no effect to the servo.

 1. They are all connected to the box which has a single connection to the board ground. If I connect each of them to the ground, there would be many small loops

of ground. Of course, I should have replaced all the connectors such that the they are disconnected to the box as point out by Robert.

2. The oscillation disappears after I add 5 nF capacitor in parallel to the existing resistor. Thank you very much for pointing this out.

1. Yes. That is the bad. You should eventually replace the BNCs to the isolated ones.

2. OK. I like to emphasize again that everyone works on electronics should read data sheets more carefully and seriously because they have many important practical instructions to exploit full performance of the components. 

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.

 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.

So that we can use both Guralps for Adaptive stuff, and so that I can look at the differential ground motion spectra, I've reconnected the Guralp Seismometers to the PEM ADCU, instead of where they've been sitting for a while connected to the ASS ADC.  I redid the ASS.mdl file, so that the PEM and PEMIIR matricies know where to look for the Gur2 data.  I followed the 'make ass' procedure in the wiki.  The spectra of the Gur1 and Gur2 seismometers look pretty much the same, so everything should be all good.

There's a problem with DataViewer though:  After selecting signals to plot, whenever I hit the "Start" button for the realtime plots, DataViewer closes abruptly. 

When I open dataviewer in terminal, I get the following output:

allegra:~>dataviewer
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
msgget: No space left on device
allegra:~>framer4 msgget:msqid: No space left on device

Does anyone have any inspiration for why this is, or what the story is?  I have GR class, but I'll try to follow up later this afternoon.

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.

Thank you.

Leaving for dinner. Back in ~1hr.

I left a measurement running. Please don't interfere with it till I'm back. Thanks.

 Per Alberto's instructions, I have closed the shutter on his laser so that the Adaptive Team can play with the Mode Cleaner.

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

 This problem seems to be restricted to allegra.  Dataviewer works fine on Rosalba  and op440m, as well as using ssh -X into rosalba to run dataviewer remotely.  DTT seems to work fine on allegra.  The disk usage seems no where near full on allegra.  Without knowing which "device" its refering to (although it must be a device local to allegra), I'm not sure what to look at now. 

I'm going to do a reboot of allegra and see if that helps.

Update:  The reboot seems to have fixed the issue.

I have tried to make the quadrant magnetic levitation work but unfortunately I did not succeed. During the experiment, I have made

the following changes to the circuit and setup:

(1) I added small resistors (6K) in parallel to R11, R23, R35 and R47 (indicated in the following schematics)  to increase

the control bandwidth from 20 Hz  to 80 Hz.

(2) I changed RLED1, RLED2, RLED3, RLED4 from 2.2K to 1.5K  in the LED driver such that the current of the

LED increases and in turn the displacement sensitivity increases.

(3) I changed R51 and R51 (in the differencing block for PD1 and PD2) from 5K to 1 K. Correspondingly,

I increased R52 and R54 from 5K to 50K. This changes increase the gain in the differential control by a

factor of 50, which compensates the gain loss after increasing the control bandwidth.

 (4) The trim pots in the coil drive block have the following values: 100K for pot1 and pot4, 1K fro pot 2 and pot3.

To increase the gain, I replaced R17, R30, R31, R41 by 102 Om resistors (we run out of 100 Om chip resistors.)

(5) I wrapped the OSEM flags by plastic tubes to block the light from the LED more efficiently. This also removed

the changes of the photocurrent in the photodetector when the levitated plate moves horizontally.

Possible issues that cause the setup not working at the moment:

(1) The feedback gain could be probably still not enough. During the experiment, I can't feel any force changes when the

flags crossing the zero point. The error signals and control signal has the right sign.

(2) The levitated weight may be not enough and the working point is below the extremum of the DC attracting force.

This could give rise to a large negative spring which requires unreasonable feedback gain to compensate.

(3) The DC attracting force between the magnets are differing each other too much (mismatch) and can't

be compensated by the coil driving force.

(4) The control bandwidth may be still not  large enough. Initially my design was 100 Hz, but I forgot to divide

the angular frequency by 2pi and the resulting circuit has a bandwidth of 20 Hz. Later I increase it up to 80 Hz

by changing the resistors as mentioned before.

(5) The polarization of the coil could have a wrong sign. I have checked with Gauss meter, but still the absence

of zero-point crossing force change makes me worry about this.

For continuation of this work, I will finish writing my document and summarize all the results and outline what

needs to be done in the future. If everything goes well, I will be back in June and can spend more time on this

experiment. I can also work with the summer students together on this project.

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.

The tst model wasn't compiling this morning due to some incorrect lines in the RfmIOfloat.pm file located in /home/controls/cds/advLIgo/src/epics/util/lib file on megatron. 

The error was "Undefined subroutine &CDS::RfmIOfloat::partType called at lib/Parser2.pm line 354, <IN> line 3363."

I changed RfmIO to RfmIOfloat on lines 1 and 6.
Basically the first 6 lines are now

package CDS::RfmIOfloat;
use Exporter;
@ISA = ('Exporter');

sub partType {
        return RfmIOfloat;
}

The tst now compiles.  At the moment, I believe we should be able to switch megatron in for ETMY and attempt to lock the arm.  The whitening/dewhitening filters are still not automatically synced in software and hardware, but I don't think that should prevent locking.

OAF is successfully canceling noise again, thanks to Matt!

Here is a plot showing more than a factor of 10 noise reduction around 3Hz (similar to what we saw in the simulations)

The changes that has made it work are:

• use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
• mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
• nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
• Main changes: filter bank on the PEM channels (ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32)
• Added the AI800 filter for upsampling in MC1 (should not matter)

 Matt suggested playing with the emphasis (EMPH) filters to cancel noise in different frequency bands.

This afternoon we attempted to lock the interferometer using Megatron insteady of the usual ETMY front end.

We attempted it once, found the alignment seemed particularly bad, then realized we had forgotten to add the QPDs.  In the process of adding the QPDs to the tst.mdl file, we realized I (Joe) should have been looking at the iscNetDsc.h file, not the iscNetDs40m.h file for the RFM memory structure.  The only major difference was the memory location of where the qpd information gets passed.

We added QPDs to the tst.mdl file, writing to the RFM network with the QPD pitch, yaw and sum values.

We also added normalization to the oplev, by dividing the OL pitch and yaw values by the OL sum value in the tst.mdl file.

The lscPos, ascPit, ascYaw were working properly, although we did have to poke at the ascPit and ascYaw values once before they started reading properly at Megatron (they started at -1e20).  We think the RFM card may have started in an odd state, and without something causing the ascPit and ascYaw values to change, it never updated.

At the end of the day, the interferometer was locked for a few seconds.  There is are still some issues to be worked on, but its progress.

Koji returned everything back to normal operations after the test.

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.

The first design of the triple resonant EOM circuit has been done.

If only EOM has a loss of 4 Ohm, the gain of the circuit is expected to be 11 at 55MHz

So far I've worked on investigation of the single resonant circuit and accumulated the knowledge about resonant circuits.

Then I started the next step, designing the triple resonant circuit.

Here I report the first design of the circuit and the expected gain.

( What I did )

At first in order to determine the parameters, such as inductors and capacitors, I have solved some equations with numerical ways (see the past entry).

In the calculation I put 6 boundary conditions as followers;

(first peak=11MHz, second peak=29.5MHz, third peak=55MHz, first valley=22MHz, second valley=33MHz, Cp=18pF)

The valley frequencies of 22MHz and 33MHz are chosen in order to eliminate the higher harmonics of 11MHz, and Cp of 18pF represents the capacitance of the EOM.

Basically the number of parameters to be determined is 6 ( L1, L2, ...,), therefore it is completely solved under 6 boundary conditions. And in this case, only one solution exists.

The point is calculation does not include losses because the loss does not change the resonant frequency.

( results )

As a result I obtained the 6 parameters for each components shown in the table below.

Then I inserted the loss into the EOM to see how the impedance looks like. The loss is 4 Ohm and inserted in series to the EOM. This number is based on the past measurement .

Let us recall that the gain of the impedance-matched circuit with a transformer is proportional to square-root of the peak impedance.

It is represented by G = sqrt(Zres/50) where Zres is the impedance at the resonance.

 As you can see in the figure, Zres = 6.4 kOhm at 55MHz, therefore the gain will be G=11 at 55MHz.

Essentially this gain is the same as that of the single resonant circuit that I've been worked with, because its performance was also limited mainly by the EOM loss.

 An interesting thing is that all three peaks are exactly on the EOM limited line (black dash line), which is represented by Zres = L/CR = 1/ (2pi f Cp)^2 R. Where R = 4 Ohm.

( next plan )

There are other solutions to create the same peaks and valleys because of the similar solution.

 It is easy to understand if you put Cp' = Cp x N, the solutions must be scaled like L1'=L1/N, C1'=C1 x N, ...,  Finally such scaling gives the same resonant frequencies.

So the next plan is to study the effect of losses in each components while changing the similar solution.

After the study of the loss I will select an optimum similar solution.

Very cool.         

The design of the triple resonant circuit has been fixed.

I found the optimum configuration, whose gain is still 11 at 55MHz even if there are realistic losses.

As I mentioned in the last entry, there are infinite number of the similar solutions to create the same resonant frequencies.

However owing to the effect of the losses, the resultant gain varies if the similar solution changes

The aim of this study is to select the optimum solution which has a maximum gain ( = the highest impedance at the resonance ).

In order to handle the losses in the calculation, I modeled the loss for both inductors and the capacitors.

Then I put them into the circuit, and calculated the impedance while changing the solutions.

(method)

1). put the scaling parameter as k in order to create the similar solution.

2). scale the all electrical parameters (L1, L2,...) by using k, so that C1'=C1 x k, L1'=L1/k ,...

3). Insert the losses into all the electrical components

4). Draw the impedance curve in frequency domain.

5). See how the height of the impedance at the resonance change

6). Repeat many time this procedure with another k.

7). Find and select the optimum k

There is a trick in the calculation.

I put a capacitor named Cpp in parallel to the EOM in order to scale the capacitance of the EOM (see the schematic).

For example if we choose k=2, this means all the capacitor has to be 2-times larger.

For the EOM, we have to put Cpp with the same capacitance as Cp (EOM). As a result these two capacitors can be dealt together as 2 x Cp.

So that Cpp should be Cpp = (k-1) Cp, and Cpp vanishes when we choose k=1.

The important point is that the scaling parameter k must be greater than unity, that is k > 1.

This restriction directly comes from Cp, the capacitance of the EOM, because we can not go to less than Cp.

If you want to put k < 1, it means you have to reduce the capacitance of the EOM somehow (like cutting the EO crystal ??)

(loss model)

I've modeled the loss for both the inductors and the capacitors in order to calculate the realistic impedance.

The model is based on the past measurements I've performed and the data sheet.

   Loss for Capacitor :  R(C) = 0.5 (C / 10pF)^{-0.3} Ohm

   Loss for Inductor :    R(L) = 0.1 ( L / 1uH) Ohm

Of course this seems to be dirty and rough treatment.

But I think it's enough to express the tendency that the loss  increase / decrease monotonically as  L / C get increased.

These losses are inserted in series to every electrical components.

( Note that: this model depends on both the company and the product model. Here I assume use of Coilcraft inductors and mica capacitors scattered around 40m )

( results )

The optimum configuration is found when k=1, there is no scaling. This is the same configuration listed in last entry

Therefore we don't need to insert the parallel capacitor Cpp in order to achieve the optimum gain.

The figure below shows the some examples of the calculated impedance. You can see the peak height decrease by increasing the scale factor k.

The black dash line represents the EOM-loss limit, which only contains the loss of the EOM.

The impedance at the resonance of 55MHz is 6.2 kOhm, which decreased by 3% from the EOM-loss limit. This corresponds to gain of G = 11.

The other two peaks, 11MHz and 29.5MHz dramatically get decreased from EOM-loss limit.

I guess this is because the structure below 50MHz is mainly composed by L1, L2, C1, C2.

In fact these components have big inductance and small capacitance, so that it makes lossy.

( next step )

The next step is to choose the appropriate transformer and to solder the circuit.

The design looks very good. I have some questions.

1. As far as I remember, you've got the gain of slightly worse than 10 for a 55MHz single resonant case. Why your expectation of the gain (G=11) for the highest resonance better than this?

Supposing the loss exists only on the EOM, the other part of the LC network for the triple work as an inductor at the resonant frequency. This is just equivalent as the single resonant case. So the expected gain at 55MHz should coincides with what we already have. Probably, the resistance of 4 Ohm that is used here had too rough precision???

2. How can you adjust the resonances precisely?

Do we need any variable components for Cs and Ls, that may have worse quality than the fixed one, generally speaking.
I myself has no experience that I had to tune the commercial EOM because of a drift or whatever. I hope if you can adjust the resonance with a fixed component it should be fine.

3. Changing Cp. What does it mean?

Do you put additional cap for Cp?

4. The resonances for the lower two look very narrow. Is that fine?

This will show up in a better shape if we look at the transfer function for the gain. Is this right?

If we have BW>100kHz, it is sufficient.

5. Impedance matching for the lower two resonances.

Yep. You know this problem already.

Self-follow:

I got the answer of Q3 from the follow-up entry.

For Q4, once you get the impedance of the LC network lower than n^2*50, the EOM gain will be quite low. This means that the resonance is anyway narrow.
I did some simple calculation and it shows that the width of the resonance will be 100kHz~500kHz. So it maybe OK.

First I was confused, but now I think I understood.

My confusion:
If the k get bigger, L get smaller, C get bigger. This makes R(L) smaller and R(C) smaller. This sounds very nice. But why smaller k is preferable in the Kiwamu's result?

Explanation:
The resultant impedance of the network at a resonance is determined by Zres = L/(R C) or something like that. Here R = R(L)+R(C). (I hope this is right.)

Here larger Zres is preferable. So smaller R is nice.

But If the speed of reduction for R is slower than that of L/C (which is proportional to k^-2), increasing k does not help us to increase of Zres. And that's the case.

This means "if we can put the LC network in the box of EOM, we can do better job!" as we can reduce Cp.

1. You are right, the gain for the single resonant circuit was about 9.3 in my measurement.

But the reason why the triple is better than the single resonant circuit comes from the transformer.

The impedance can be degraded by a loss of the transformer, because it got worse after applying the transformer in the past measurement.

Also I definitely confirmed that the circuit had the impedance of 7.2 kOhm at the resonance of 52.9MHz without the transformer.

So it shall give the gain of 12, but did not after applying the transformer.

2.  Yes, I think we need some variable components just in case.

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.