Peter and Koji,

We are constructing a setup for the new 40m CDS using Realtime Code Generator (RCG).
We are trying to put simulated suspensions and test suspension controllers on a different processors of megatron
in order to create a virtual control feedback loop. Those CDS processes are communicating
each other via a shared memory, not via a reflective memory for now.

After some struggles with tremendous helps of Alex, we succeeded to have the communication between the two processes.
Also we succeeded to make the ADC/DAC cards recognized by megatoron, using the PCI express extension card replaced by Jay.
(This card runs multi PCI-X cards on the I/O chasis.)

Next steps:
- Establish a firewall between the 40m network and megatron (Remember this)
- Make DTT and other tools available at megatron
- Try virtual feedback control loops and characterize the performance
- Enable reflective memory functionalities on megatron
- Construct a hybrid system by the old/new CDSs
- Controllability tests using an interferometer

Note on MATLAB/SIMULINK
o Each cdsIPC should have a correct shared memory address spaced by 8 bytes. (i.e. 0x1000, 0x1008, 0x1010, ...)

Note on MEDM
o At the initial state, garbage (e.g. NaN) can be running all around the feedback loops. They are invisible as MEDM shows them as  "0.0000".
To escape from this state, we needed to disconnect all the feedback, say, by turning off the filters.

Note on I/O chasis
o We needed to pull all of the power plugs from megatron and the I/O chasis once so that we can activate
the PCI-e - PCI-X extension card. When it is succeeded, all (~30) LEDs turn to green.

 I checked the setup and found RF reflection at the load was the cause of the unreasonable response in the impedance measurement.
So, I have put a total 22dB attenuation (10+6+6 dB) between the power splitter and the load to be measured. See the picture.
This kind of attenuators, called as PADs, is generally used in order to improve the impedance matching, sacrificing the signal amplitude at the load.

Then, It looks the measurements got reasonable up to 100MHz (at least) and |Z|<1kOhm.
For the measurements, I just followed the procedure that Stephanie described.
Stephanie has measured the impedance of her resonant circuit.

As a test of the method, I measured impedances of various discrete devices. i.e. 50Ohm, 10-1000pF Cap, Inductances, circuit opened.

a) 50Ohm (marine-blue) was calibrated to be recognized as 50Ohm.

b) The mica capacitances (orange 10pF, yellow 100pF, green 1000pF) appeared as the impedances f^-1 in the low freq region. It's nice.
At high frequency, the impedances deviate from f^-1, which could be caused by the lead inductance. (Self Resonance)
So 1000pF mica is not capacitance at 50MHz already.

c) Open BNC connector (Red) looks have something like 5pF. (i.e. 300Ohm at 100MHz)

d) I could not get good measurements with the inductors as I had 200nH (and some C of ~5pF) for a Pomona clip (blue).
This is just because of my laziness such that I avoid soldering the Ls to an RF connector!

Stephanie and Koji

We left two carts near the PSL table.
We are using them for characterization of the tripple resonant EOM.

nodus was rebooted by Alex at Fri Aug 14 13:53. I launched elogd.

cd /export/elog/elog-2.7.5/
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D

Jenne, Koji

The cause of the decrease was found and the problem was solved. We found this entry, which says

Yoich> We opened the MOPA box and installed a mirror to direct a picked off NPRO beam to the outside of the box through an unused hole.
Yoich> We set up a lens and a PD outside of the MOPA box to receive this beam. The output from the PD is connected to the 126MON cable.

We went to the PSL table and found the dc power cable for 126MOPA_AMPMON was clipping the 126MON beam.
We also made a cable stay with a pole and a cable tie.

After the work, 126MON went up to 161 which was the value we saw last night.

We also found that the cause of the AMPMON signal change by the DAQ connection, mentioned in this entry:

Jenne> 6.  We teed off of the AMPMON photodiode so that we could see the DC values on a DMM. 
Jenne> When we used a T to connect both the DMM and the regular DAQ cable, the DMM read
Jenne> a value a factor of 2 smaller than when the DMM was connected directly to the PD.

We found a 30dB attenuator is connected after the PD. It explains missing factor of 2.

I ran (script dir)/PSL/FSS/SLOWscan on op440m from 11:30 to 12:30 on 27th. Although Rana and later I myself set "timed bombs" for the scan, they did not work as they have probably been ran on Linux. After the scan I relocked PMC, FSS, and MZ . MC locked automatically.

Observation:

1. To keep away from the mode hop, FSS_SLOWDC is to be at around 0. The values -5 ~ -6 is the place for the power, which is my preference for now. BTW, the mode hop only appears to the PSL output (=AMPMON) is this normal?

2. The PSL output looks dependent on the NPRO wavelength. The NPRO output and the PSL output tends to be high when the FSS_SLOWDC is low (= LTMP: Laser Crystal Temp is low). Also there is a step at the LTMP where we think the mode hop is present. This may cause the daily PSL output variation which induced by the daily change of the reference cavity length.

My naive speculation is that the NPRO wavelength is too long (= hot side) for the MOPA absorption as the MOPA heads are cooled to 19deg.

3. Scanning of -10 to +10 changes the LTMP from 42-49deg. This is almost 1/10 of the NPRO capability. The manual told us that we should be able to scan the crystal temperature +/-16deg (about 30deg to 60deg).

What I like to try:
a) Change the NPRO temp to more cold side.
b) Change the MOPA head temp to a bit hot side.
c) Tweak the MOPA current (is it difficult?)

Jenne, Koji

Tonight we found that the wireless for Martian network was down.
We inspected the router and found the power was down. The power of the weather station was also down.

By touching the power outlet which they are connected, the power changes on and off.
This problematic power outlet has a label "L#17" just below the photograph of the mk I (1989).
The plug was connected to the left one.

As it was scary, we moved the power plug to the next one (L#19).
The wireless router and the weather station were powered now,
though the weather station is showing a wrong time in its clock.

Rana, Jenne, Koji

Last night we checked MZ. The apparent thing we found was the gain slider does not work.
The slider actually changes the voltage at the cross connection of 1Y2 (31 pin4?), the gain does not change.
The error spectrum didn't change at all even when the slider was moved.

Rana poked the flat cable at the bottom of 1Y2, we had no imporvement.

We coudn't find the VME extender board, so we just replaced AD602 (=VGA) and LT1125 (=Buffer for the ctrl voltage).
Even after the replacement, the gain slider is not working yet.

Today, I will put a lead or probe to the board to see whether the slider changes the voltage on the board or not.

Somehow the gain is sitting at a intermediate place that is not to low not to high. So I still don't know the gain slider
is the cause of the MZ instability or not.

12:45 I started the work on MZ. Thus the MZ was unlocked.

Found the bad connection on the FLKM 64pin cross connection board. We need a replacement.

I went to Wilson and got the replacement, two VME extender boards, three 7815, and three 7915. Thanks, Ben!

The MZ work completed. I replaced the bad cross connection terminal. The gain slider is working now.

I looked at the error spectrum on an FFT analyzer. I could see the lock was more tight.

Then I proceeded to the MZ epics panel.

1) C1:PSL-MZ_MZTRANSPD has no meaning (not connected). So I put  C1:PSL-ISS_INMONPD as the MZ trans monitor.

2) The EPICS setting for the MZ gain slider was totaly wrong.
    Today I learned from the circuit, the full scale of the gain slider C1:PSL-MZ_GAIN gave us +/-10V at the DAC.
    This yield +/-1V to V_ctrl of the AD602 after the internal 1/10 attenuation stage.
    This +/-1V didn't correspond to -10dB~+30dB, but does -22dB~+42dB and is beyond the spec of the chip.

    The gain of AD602 is calculated by

G [dB] = 32 V_crtl + 10,  for -0.625 [V]< V_ctrl < +0.625 [V].

    In order to fix this I used the following commands which overrode the EPICS parameters.
    The tip of EGUF/EGUL is to know how much the gain (virtually) goes for the full scale of the DAC output. 

ezcawrite C1:PSL-MZ_GAIN.EGUF 42
ezcawrite C1:PSL-MZ_GAIN.EGUL -22
ezcawrite C1:PSL-MZ_GAIN.DRVH 30
ezcawrite C1:PSL-MZ_GAIN.DRVL -10
ezcawrite C1:PSL-MZ_GAIN.HOPR 30
ezcawrite C1:PSL-MZ_GAIN.LOPR -10

   and for the permanent change I modified the db file /cvs/cds/caltech/target/c1iool0/c1iooMZservo.db
   This will be active when cliool0 is rebooted.

# This yields the output limited to -6.25V ~ +6.25V, which corresponds to -10dB ~ +30dB
# modified by Koji Arai (29-Sept-2009)
grecord(ao,"C1:PSL-MZ_GAIN")
{
        field(DESC,"GAIN- overall pre-modecleaner servo loop gain")
        field(SCAN,"Passive")
        field(PINI,"YES")
        field(DISV,"1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C3 S5 @")
        field(EGUF,"42")
        field(EGUL,"-22")
        field(PREC,"1")
        field(EGU,"dB")
        field(HOPR,"30")
        field(LOPR,"-10")
        field(DRVH,"30")
        field(DRVL,"-10")
        field(LINR,"LINEAR")
        field(OROC,"0")
        field(DOL,"0")
}

# previous code
grecord(ao,"C1:PSL-MZ_GAIN")
{
        field(DESC,"GAIN- overall pre-modecleaner servo loop gain")
        field(SCAN,"Passive")
        field(PINI,"YES")
        field(DISV,"1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C3 S5 @")
        field(EGUF,"30")
        field(EGUL,"-10")
        field(PREC,"4")
        field(EGU,"Volts")
        field(HOPR,"30")
        field(LOPR,"-10")
        field(LINR,"LINEAR")
        field(OROC,"0")
        field(DOL,"0")
}

The previous "+15" was Vctrl = 0.25 [V]. Which was +18 dB.

Probably there is the same mistake for the PMC gain slider. Possibly on the FSS slider, too???

MZ stayed unlocked. Now It was relocked.

I will investigate the MZ board. I will unlock MZ (and MC).

MZ work has been done. I did not change anything on the circuit.

Recently we observed that the MZ PZT output was sticking at a certain voltage. I found the reason.
Shortly to say "we must return the PZT Ramp offset to 0, after the lock"

I am going to write a MZ auto lock script someday, to do it automatically.

According to the resister values used in the circuit, the PZT HV output voltage is determined by the following formula:

V_PZT = 150 - 12 V_ctrl - 24 Vramp

Here the ramp voltage Vramp moves from -10V to +10V, the feedback control voltage V_ctrl moves from -13V to +13V.
The baseline offset of 150V is provided in the circuit board.

When V_ramp is 0, V_PZT runs from 0 to 300. This is just enough for the full scale of the actual V_PZT range,
that is 0V~280V.

If any Vramp offset is given, V_PZT rails at either side of the edges. This limits the actual range of the PZT out.

This is not nice, but is what happened recently.

Ops. I restored the damping of the suspensions at around 16:30.

The PSL output looks smaller than the incident. Try to FSS Slow actuator adj of -5.6 (nominal), instead of -3.5.

I set the FSS slow actuator adj to -5.6 at the lunch time. It gave a little help at that time. Now max of the MC Trans is comming back somehow. I hope the MC Trans level is as good as before, if the HEPA is slowed down.

Awesome.

I propose that anyone who tries to do this kind of thoroughgoing cleaning should make an e-mail to call everyone available to join just for some hours
because every member has a responsibility to keep the lab organized.

And we have the list of things to do: Electronics (now it is halfway) / Cables / Optics / Screws / Tools ...

Last night (Oct 07), I ran armLoss script in order to obtain the latest numbers for the arm cavity loss.
Here is the summary

Parameters:

TE=10ppm, LE=L_RT/2, RE=1-TE-LE
tE=Sqrt(TE), rE=Sqrt(RE)

TF=0.005, LF=L_RT/2, RF=1-TF-LF
tF=Sqrt(TF), rF=Sqrt(RF)

rcav = -rF +(tF^2 rE)/(1-rF rE)
R_cav = rcav^2

F = pi Sqrt(rF rE)/(1-rF rE)

I looked at the data of the day before yesterday (Oct 06) to know how much is the recycling gain.

X arm: (TRX_PRecycled) / (TRX_PRMmisaligned) * T_PRM = 83.1/0.943*0.07 = 6.17
Y arm: (TRX_PRecycled) / (TRX_PRMmisaligned) * T_PRM = 99.2/1.017*0.07 = 6.83

==> G_PR = 6.5 +/- 0.5     (oh...this estimation is so bad...)

From the recycling gain and the arm cavity reflectance, one can get the loss in the recycling cavity.

G_PR = T_PRM  / (1-Sqrt(R_PRM * (1-L_PRC)*R_cav))^2

==> loss in the recycling cavity L_PRC: 0.009+/-0.009
       (About 1% loss is likely in the recycling cavity)

Steve, Kiwamu, and Koji

We went through the PSL table to make sure any strong beam did not hit the wall.

We found that the reflection of Stephanie's OSA returned its path down to the beamsplitter.
This BS reflect that beam to the wall. That was fixed.

The surprising was that the relatively strong beam (~1mW?) went through the steering mirror
just before the PMC. We put thorlabs razor blades. I am still thinking what this indicates...
because the beam had been blocked if it was such from long time before.

During the work we found some stray optics such as a cube BS, a flipper mirror, and so on.
We can see them in the photo as those enclosed with yellow circles.
One of the beams was obtained from the reflection of the ND filter (...almost illeagal), and 
was even hittting a metal fixture for the BS cube.

If someone uses these components for useful purposes,
please let me(Koji) know. Otherwise, they are removed next week.

The other thing we found was the bright scatter from the EOM for the PMC.
As this scatter is so blight, I am going to align it.

OK! I saw the optics are redundant and some of the components are not in a right place.
I will talk with you when you are back such that we can keep the usefulness of the setup.

Some questions came arise to me:

A. How the green injection system should be? How the handing off between 532 and 1064 should be?

This is not new, though. It would be worth reminding.

B. Do we still need PMC if we use 2W innolight?

Innolight has low intensity noise at the detection freq. Also the spacial mode is clean.

C. Do we still need frequency prestabilization by RC?

Is the stabilization of the laser freq by the MC not enough?
What is the relationship with the green?

Could be this.

http://ilog.ligo-la.caltech.edu/ilog/pub/ilog.cgi?group=detector&task=view&date_to_view=10/02/2009&anchor_to_scroll_to=2009:10:02:13:33:49-waldman

You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL_Table_Diagram

Thanks. I love this. Could you also put the original file that is editable for future modification by anyone?

Diagram. I don't want to say PNG is an editable format for this purpose...
You have the PPT, PDF or any drawing format to create this diagram.

I adjusted the steerings to the PMC and gained 7%. Now the MC_TRANS 7.0 has been recovered.

Actually I need another 7% to get MC_TRANS 7.5.
But I couldn't find how I can recover 126MOPA-AMPMON to 2.8ish.

I was working on the ISS excitation to take TFs.

I used ISS IL excitation, stealing from a small box on the floor for the OMC.

All the configuration was restored except that the HEPA is on.

13:00 Found MC TRANS less than 7.
13:50 Go into the PSL table.
14:20 Work done. Now I am running SLOWscan script.
15:10 SLOWscan finished. It was not satisfactory. I go into the table again.
15:15 Running SLOWscan again.
16:00 SLOWscan done. Lock PMC. Adjust NPRO current so as to maximize PMC TRANS.
16:10 Lock RC, PMC, MZ, MC. Align PMC / MZ on the table. Align MC WFS beams on the QPDs.
16:30 Work done.

New FSS-SLOWDC nominal is -4.0

Now MC TRANS is 7.9. This is +12% increase. ENJOY!
HEPA is on at 90%. Light is off.

---------

NPRO TEMP trimmer adjustment
o PSL NPRO TEMP trimmer at the back of the laser head was turned 6.5 times in CW.
o It reduced NPRO crystal temp by 9.5deg. (43.5deg -> 34.0deg for FSS_SLOWDC -5.5)

To revert the previous setting, refer to the former measurement
c.f. http://nodus.ligo.caltech.edu:8080/40m/2008

NPRO Thermal scan
o 2 scans are performed.
o I selected the colder side of the second scan. i.e. SLOWDC=-4.0

NPRO Current adjustment
o Tweaked C1:PSL-126MOPA_126CURADJ while looking at PMC TRANS.
o CURADJ was changed from -2.25 to -1.9. This corresponds to change of C1:PSL-126MOPA_CURMON from 2.503A to 2.547A.

Here is the plots for the powers. MC TRANS is still rising.

What I noticed was that C1:PSL-FSS_PCDRIVE nolonger hit the yellow alert.
The mean reduced from 0.4 to 0.3. This is good, at least for now.

The beam to PMC aligned. The beam to MC WFS cameras aligned.
PMC Trans increased from 2.73 to 2.75 (+1%).
MC Trans increased from 7.80 to 7.87 (+1%).

For the CDS upgrade preparation I put and moved those stuff at the rack 1Y9:

Placed 1Y9-12 ADC to DB44/37 Adapter LIGO D080397

Placed 1Y9-14 DAC to IDC Adapter LIGO D080303

Moved the ethernet switch from 1Y9-16 to 1Y9-24

Wiki has also been updated.

Joe, Peter, Jay, Koji, Rana

We put the new CDS stuff at Y end 1Y9 rack.

Items

• megatron
• wireless router
• IO chasis (black)
• Extention cable (between megatron & IO chasis)
• 1 ADC card
• 1 DAC card
• 1 BIO card
• The adapter box for ADC
• The adapter box for DAC
• The adapter box for BIO
• 2x IDC-DB37 cable for the ADC box - AA chasis
• 1x IDC cable for the DAC box - Pentek
• 1x DB cable for the BIO box
• 1x +/-15V cable for the BIO box

Done! Check it out.

Yes it did.

For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.

Last night there was an activity for a calibratuon work, which I helped. I can take care of the FG.

OK. I have been keeping my eyes on the MC transmission. In deed, the MC trans has been well kept at around 7.7 since the last PSL work.
Even it was over the 8 today!

PC_DRIVE is also improving after the last PSL work!

I continued on the STAND ALONE debugging of the megatron codes.

- I succeeded to run c1aaa with ADC/DAC. (c1aaa is a play ground for debugging.)

  The trick was "copy DAC block from sam.mdl to aaa.mdl".
  I don't understand why this works. But it worked.
  I still have the problem of the matrices. Their medm screens are always blank. Needs more works.

- Also I don't understand why I can not run the build of c1tst when I copy the working aaa.mdl to tst.mdl.

- The problem Joe reported: "# of channels to be daqed" was solved by

make uninstall-daq-aaa
make install-daq-aaa



  This command is also useful.

daqconfig

- Now I am in the stable development loop with those commands

killaaa
make uninstall-daq-aaa
make aaa
make install-aaa
make install-daq-aaa
make install-screens-aaa
startaaa


  I have made "go_build" script under /home/controls/cds/advLigo

usage:
./go_build aaa

- Note for myself: frequently visited directories

/home/controls/cds/advLigo/src/epics/simLink (for model)
/home/controls/cds/advLigo (to build)
/cvs/cds/caltech/target/c1aaa (realtime code log)
/cvs/cds/caltech/target/c1aaaepics (ioc log)
/cvs/cds/caltech/medm/c1/aaa (medm screens)
/cvs/cds/caltech/chans (filter coeffs)
/cvs/cds/caltech/chans/daq (daq settings)

I am still working on the c1aaa code. Now it seems that C1AAA is working reasonably (...so far).

1) At a certain point I wanted clean up the system status. I have visited /etc/rc.local to add c1aaa for realtime to non-realtime task

before:
/usr/bin/setup_shmem.rtl mdp mdc tst&
after:
/usr/bin/setup_shmem.rtl mdp mdc tst aaa&


   I rebooted the system several times.

sudo /sbin/reboot

2) I found that gabage medm screens accumulated in ~/cds/advLigo/build/aaaepics/medm after many trials with several simulink models.
This directory is always copied to /cvs/cds/caltech/medm/c1/aaa at every make install-screens-aaa
This caused very confusing MEDM screens in the medm dir like C1AAA_ETMX_IN_MATRX.adl (NOT ETMY!)

I did

cd ~/cds/advLigo
make clean-aaa


to refresh aaaepics dir. The current development procedure is

killaaa
make clean-aaa
make uninstall-daq-aaa
make aaa
make install-aaa
make install-daq-aaa
make install-screens-aaa
startaaa

3) Sometimes startaaa does not start the task properly. If the task does not work, don't abandon.
Try restart the task. This may help. 

killaaa
(deep breathing several times)
startaaa

What to do next:

- MEDM works

* make more convenient custom MEDM screens so that we can easily access to the filters and switches
* retrofit the conventional SUS MEDM to the new system

- once again put/confirm the filter coeffs and the matrix elements

- configure DAQ setting so that we can observe suspension motion by dataviewer / dtt

- connect the suspension to megatron again

- test the control loop

Dmass, Joe, Koji

A puzzle has been solved: Dmass gave us a great tip

"The RGC code does not work unless the name of the mdl file (simulink model) matches to the model name "

The model name is written in the second line. This is automatically modified if the mdl file is saved from simulink.
But we copied the model by using "cp" command. This prevent from the TST model working!

megatron:simLink>head tst.mdl
Model {
  Name                    "tst"
  Version                 7.3
  MdlSubVersion           0
...
...
...

This explained why the AAA model worked when the DAC block has been copied from the other model.
This was not because of the ADC block but the saving model fixed the model name mismatch!

Now our current working model is "C1TST". Most of the functionalities have been implemented now:

• The simulink model has been modified so that some of the functionalities can be accomodated, such as LSC/ASC PIT/ASC YAW.
• Some filter names are fixed so as to inherit the previous naming conventions.
• The SUS-ETMY epics screen was modified to fit to the new channel names, the filter topologies, and the matrices.
• The chans file was constructed so that the conventional filter coefficients are inherited.
• All of the gains, filter SWs, matrix elements have been set accordingly to the current ETMY settings.
• burt snapshot has been taken: /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap
burtrb -f /cvs/cds/caltech/target/c1tstepics/autoBurt.req -o controls_1091117_024223_0.snap -l /tmp/controls_1091117_024215_0.read.log -v

What to do next:

• Revisit Oplev model so that it accomodates a power normalization functionality.
• ETMY QPD model is also missing!
• Clean up mdl file using subsystem grouping

• Check consistency of the whitening/dewhitening switches.
• Connect ADC/DAC to megatron
• Test of the controllability
• BTW, what is happened to BIO?
• Implementation of the RFM card

Directories and the files:

• The .mdl file is backed up as
/home/controls/cds/advLigo/src/epics/simLink/tst.mdl.20091116_2100


• The default screens built by "make" is installed in
  /cvs/cds/caltech/medm/c1/tst/
They are continuously overridden by the further building of the models.


• The custom-built medm screens are stored in
/cvs/cds/caltech/medm/c1/tst/CustomAdls/

The backup is
/cvs/cds/caltech/medm/c1/tst/CustomAdls/CustomAdls.111609_2300/


• The custom-built chans file is
/cvs/cds/caltech/chans/C1TST.txt

The backup is
/cvs/cds/caltech/chans/C1TST.111609


• burt snap shot file
  /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap


I have connected ETMY sus electronics to megatron ADC/DAC.
We continue this state until 15:00 of today. (Restored 13:00)

0) Now the connection for the ETMY suspension was restored in a usual state. It damps well.

1) I thought it would be nice to have dataviewer and DTT working.
   So far, I could not figure out how to run daqd and tpman.
   - I tried to configure
    /cvs/cds/caltech/target/fb/daqdrc
    /cvs/cds/caltech/target/fb/master
    /cvs/cds/caltech/chans/daq/C1TST.ini (via daqconfig)

   - I also looked at
    /cvs/cds/caltech/targetgds/param/tpchn_C1.par
   but I don't understand how it works. The entries have dcuids of 13 and 14 although C1TST has dcuid of 10.
   The file is unmodified.

   I will try it later when I got a help of the experts.

2) Anyway, I went ahead. I tried to excite suspension by putting some offset.

It seems to have no DAC output. I checked the timing signal. It seems that looks wrong clock.

   I looked at DAC output by putting 5000,10000,15000,20000,25000cnt to UL/UR/LR/LL/SD coils.
   I could not find any voltage out of the DAC in any channels.

   Then, I checked the timing signal. This clock seems to have wrong frequency.
   What we are using now is a clock with +/-4V@4MHz. (Differential)
   Maybe 4194304Hz (=2^22Hz)?

   I went to 1Y3 and checked the timing signal for 16K. This was +/-4V@16kHz. (Diffrential)

   The possible solution would be
   - bring a function generator at the end and try to input a single end 4V clock.
   - stretch a cable from 1Y3 to 1Y9. (2pin lemo)

OK. Now, Timing/ADC/DAC are working. It's almost there.

1) As a temporaly clock, I put a function generator at the back side of the ETMY.
Set it to the rectangular +/-4V@16384Hz. Connect it to D060064 PCIX Timing Interface Board in the IO Chasis.
That is a line receiver to feed the TTL signal into ADCs/DACs.

I confirmed the actual sampling clock is supplied to the ADC/DAC boards by looking at the SMB output of the D060064.

2) Restarted the realtime code.

3) I looked at DAC output by putting 5000,10000,15000,20000,25000cnt to UL/UR/LR/LL/SD coils again.
Yes! I could see the DAC channels are putting DC voltages.

4) Then I connected DAC CH0 to ADC CH0 using SCSI breaking up boards.
Yes! I could see the coil output switching change the ADC counts!

Now, we are ready to see the suspension damped. Check it out.

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

How can I get those values from the figure?