The front ends seem to have different gps timestamps on the data than the frame builder has when receiving them.
One theory is we have fairly been doing SVN checkouts of the code for the front ends once a week or every two weeks, but the frame builder has not been rebuilt for about a month.
Alex is currently rebuilding the frame builder with the latest code changes.
It also suggests I should try rebuilding the frame builder on a semi-regular basis as updates come in.
[Kiwamu, Jenne, Koji, Suresh]
The following steps in this process were completed.
1) Secured the current ETMX (Old ETMY) with the earth quake stops.
2) Removed the OSEMs and noted the Sl no. of each and its position
3) Placed four clamps to mark the location of the current ETMX tower (Old ETMY's position on the table)
4) Moved the ETMX (Old ETMY) tower to the clean table flow bench. In the process the tower had to be tilted during removal because it was too tall to pass upright through the vacuum chamber port. It was scary but nothing went wrong.
5) Koji calculated the location of the new ETMX and told us that it should be placed on the north end of the table.
6) Moved the OSEM cables, counter balancing weights and the 'chopper' out of the way. Had to move some of the clamps securing the cables.
7) Moved the ETMU07 tower from the clean room to the ETMX table
8) Positioned the OSEMs as they were placed in the earlier tower and adjusted their position to the middle of the range of their shadow sensors. The four OSEMs on the face did not give us any trouble and were positioned as required. But the side OSEM could not be put in place. The magnet on the left side, which we are constrained to use since the tower is not designed to hold an OSEM on the right side, seems a little too low (by about a mm) and does not interrupt the light beam in the shadow sensor. The possible causes are
a) the optic is rotated. To check this we need to take the tower back to the clean room and check the location of the optic with the traveling microscope. If indeed it is rotated, this is easy to correct.
b) the magnet is not located at the correct place on the optic. This can also be checked on the clean room optical bench but the solution available immediately is to hold the OSEM askew to accommodate the magnet location. If time permits the magnet position can be corrected.
We have postponed the testing of the ETMU07 tower to 1st of Nov Dec.
Restarted the elog again, this time using .../elog/start-elog.csh, which Joe pointed out works just fine. I have amended the wiki instructions to point to this script, instead.
We put ETMX back in its tower, and confirmed its balance. It might be pointing a teensy bit upward, but it is way less than the DC pointing offset we see when we put the OSEMs in the towers (since the PDs and LEDs have some magnetic bits to them).
Discussions are ongoing as to where the ETM should sit on its table, but we'll probably toss it into the chamber later this evening.
I took ETMY out of the magnet gluing fixture, and put it in a ring, in the foil house. It is ready to have the wire winched and get balanced at our convenience.
The updated status table:
1) Turns out the /opt/rtcds/caltech/c1/target/gds/param/testpoint.par file had been emptied or deleted at one point, and the only entry in it was c1pem. This had been causing us a lack of test points for the last few days. It is unclear when or how this happened. The file has been fixed to include all the front end models again. (Fixed)
2) Alex and I worked on tracking down why there's a GPS difference between the front ends and the frame builder, which is why we see a 0x4000 error on all the front end GDS screens. This involved several rebuilds of the front end codes and reboots of the machines involved. (Broken)
3) Still working on understanding why the RFM communication, which I think is related to the timing issues we're seeing. I know the data is being transferred on the card, but it seems to being rejected after being red in, suggesting a time stamp mismatch. (Broken)
4) The c1iscex binary output card still doesn't work. (Broken)
Alex and I will be working on the above issues tomorrow morning.
Currently, the c1ioo, c1sus and c1iscex computers are running with their front ends. They all still have 0x4000 error. However, you can still look at channels on dataviewer for example. However, there's a possibility of inconsistent timing between computer (although all models on a single computer will be in sync).
All the front ends where burt restorted to 07:07 this morning. I spot checked several optic filter banks and they look to have been turned on.
I didn't realize that the script in .../elog was configured to start 2.8.0 already. I will revert the instructions on the wiki to point to that
Last night I found that the response of ITMX against the angle offsets were strage.
Eventually I found a loose connection at the feedthrough connectors of ITMX chamber.
So I pushed the connector hard, and then ITMX successfully became normal.
It looked like someone had accidentally kicked the cable during some works.
This bad connection had made unacceptable offsets in the OSEM readout, but now they seem fine.
We seemed to have a broken fiber link for use between the LSC and its IO chassis. It is unclear to mean when this damage occurred. The cable had been sitting in a box with styrofoam padding, and the kink is in the middle of the fiber, with no other obvious damage near by. The cable however may have previously been used by the people in Downs for testing and possibly then. Or when we were stringing it, we caused a kink to happen.
I talked to Alex yesterday, and he suggested unplugging the power on both the computer and the IO chassis completely, then plugging in the new fiber connector, as he had to do that once with a fiber connection at Hanford. We tried this this morning, however, still no joy. At this point I plan to toss the fiber as I don't know of any way to rehabilitate kinked fibers.
Note this means that I rebooted c1sus and then did a burt restore from the Nov/30/07:07 directory for c1suspeics, c1rmsepics, c1mcsepics. It looks like all the filters switched on.
We do, however, have the a Dolphin fiber which originally was intended to go between the LSC and its IO chassis, before Rolf was told it doesn't work well that way. However, we were going to connect the LSC machine to the rest of the network via Dolphin.
We can put the LSC machine next to its chassis in the LSC rack, and connect the chassis to the rest of the front ends by the Dolphin fiber. In that case we just need the usual copper style cable going between the chassis and the computer.
The elog seemed to be down at around 12:05pm. I waited a few minutes to see if the browser would connect, but it did not.
I used the existing script in /cvs/cds/caltech/elog/ (as opposed to Zach's new on in elog/elog-2.8.0/) which also seems to have worked fine.
I have created an updated version of the "start-elog-nodus" script and put it in .../elog/elog-2.8.0. It seems to work fine.
As a result of the vacuum work, now the IR beam is hitting ETMX.
The spot of the transmitted beam from the cavity can be found at the end table by using an IR viewer.
(today's missions for IOO)
- cabling for the pzt mirrors
- energizing the pzt mirrors and slide them to their midpoint.
- locking and alignment of the MC
- realignment of the pzt mirrors and other optics.
- letting the beam go down to the arm cavity
ETMU05 : Gluing Side magnets back on to the optic.
The following steps taken in this process:
1) The two magnet+dumbell units which had come loose from the optic needed to be cleaned. A lint free wipe was placed on the table top and a few cc of acetone was poured on to it. The free end of the dumbbell was then scrubbed on this wipe till the surface regained its shine. The dumbell was held at its narrow part with a forceps to avoid any strain on the magnet-dumbbell joint.
2) The optic was then removed from its gluing fixture (by loosening only one of the three retaining screws) and placed in an Al ring. The glue left behind by the side magnets was scrubbed off with a optical tissue wetted with Acetone.
3) The optic was returned to the gluing fixture. The position of the optic was checked by inserting the brass portion of the gripper and making sure that the face magnets are centered in it [Jenne doubled checked to be sure we got everything right].
4) The side magnets were glued on and the optic in the fixture has been placed in the foil-house.
If all goes well we will be able to balance the ETMU05 and give it to Bob for baking.
ETMU07 : It is still in the oven and we need to ask Bob to take out. It will be available for installation in the 40m tomorrow.
I installed the following packages on Graphviz in order to support visualization of GStreamer pipeline graphs:
The elog was down so I restarted it. The instructions on the wiki do not work as the process has some complicated name (i.e. it is not just 'elogd'). I used kill and the pid number.
I will get around to updating the restart script to work with 2.8.0.
This morning I opened the chambers and started some in-vac works.
As explained in this entry, I swapped pzt mirror (A) and (C) successfully.
The chambers are still open, so don't be surprised.
I uploaded some pictures taken in the last and this week. They are on the Picasa web albums.
in vac work [Nov. 18 2010]
in vac work [Nov 23 2010]
CDS work [Nov 24 2010]
We tried installing C1LSC but it's not completely done yet due to the following issues.
(1) A PCIe optical fiber which is supposed to connect C1LSC and its IO chasis is broken at a high probability.
(2) Two DAC boards (blue and golden board) are missing.
We will ask the CDS people at Downs and take some more of those stuff from there.
( works we did )
- took the whole C1ASC crate out from the 1Y3 rack.
- installed an IO chasis to the place where C1ASC was.
- strung a timing optical fiber to the IO chasis.
- checked the functionality of the PICe optical fiber and found it doesn't work.
Fig.1 c1asc taken out from the rack Fig.2 IO chasis installed to the rack
Fig.3 PCIe extension fiber (red arrow for an obvious bended point)
I have made a little bit of progress on the PEM channels. I have begun writing up detailed instructions in the DAQ Wiki page on how to add a channel to the new DAQ system. I have followed those instructions thus far, and can see my channels in the .ini file (and in the daqconfig gui thing), but I don't have any channels in Dataviewer or DTT.
There are some tricky "gotchas" involved in creating new models and channels. Some examples include: No use of the characters "DUMMY" in any channel name. The makefile is specifically hardcoded to fail if that string of characters is used. Also, you must have at least 2 filter banks in every model. Why? No one knows. You just do. The model won't compile unless you have 2 or more filter banks.
My efforts today included ~3 reboots of the frame builder, and ~2 reboots of c1sus. When Kiwamu and I rebooted c1sus, we burt restored to some time in the last 24 hrs. Some of the SUS filters on some of the optics were not set correctly (things like the bounce roll filter), so we turned all of them on, and reset all of the input and output matricies to be the correct combination of +1 and -1's to make Pit, Pos and Yaw. The tuning seems to happen now-a-days in the gains for each DOF, and the gains were set correctly by the burt restore for every optic except PRM. We made some educated guesses for what the gains should be based on the other optics, and PRM is damping pretty well (these guesses included reducing the SIDE gain by ~10 from the BS SIDE value, since the analog gain of the PRM SIDE sensor is much higher than others). We'll have to fine tune these gains using some Yuta-developed method soon. Or find a burt snapshot that had some non-unity values in there.
We removed ETMU07 from the suspension tower, after confirming that the balance was still good. Bob put it in the oven to bake over the weekend. The spring plungers and our spare magnets are all in there as well.
I tried to remove the grippers from ETMU05, and when I did, both side dumbbells came off of the optic. Unfortunately, I was working on getting channels into the DAQ, so I did not clean and reglue ETMU05 today. However Joe told me that we don't have any ETMY controls as yet, and we're not going to do Yarm locking (probably) in the next week or so, so this doesn't really set any schedules back.
The cleaning of ETMU05 will be tricky. Getting the residual glue off of the optic will be fine, but for the dumbbells, we'd like to clean the glue off of the end of the dumbbells using a lint free wipe soaked in acetone, but we don't want to get any acetone in the magnet-to-dumbbell joint, and we don't want to break the magnet-to-dumbbell joint. So we'll have to be very careful when doing this cleaning.
The Status Table:
Wow. I typed DTT on rossa and it actually worked! No complaints about testpoints, etc. I was also able to use its new 'NDS2' function to get data off of the CIT cluster (L1:DARM_ERR from February). You have to use the kinit/kdestroy stuff to use NDS2 as usual (look up NDS2 in DASWG if you don't know what I mean).
[Joe, Suresh, Kiwamu]
We will fully install and run the new C1LSC front end machine tomorrow.
And finally it is going to take care of the IOO PZT mirrors as well as LSC codes.
During the in-vac work today, we tried to energize and adjust the PZT mirrors to their midpoints.
However it turned out that C1ASC, which controls the voltage applying on the PZT mirrors, were not running.
We tried rebooting C1ASC by keying the crate but it didn't come back.
The error message we got in telnet was :
memory init failure !!
We discussed how to control the PZT mirrors from point of view of both short term and long term operation.
We decided to quit using C1ASC and use new C1LSC instead.
A good thing of this action is that, this work will bring the CDS closer to the final configuration.
(things to do)
- move C1LSC to the proper rack (1X4).
- pull out the stuff associated with C1ASC from the 1Y3 rack.
- install an IO chasis to the 1Y3 rack.
- string a fiber from C1LSC to the IO chasis.
- timing cable (?)
- configure C1LSC for Gentoo
- run a simple model to check the health
- build a model for controlling the PZT mirrors
I installed and activated Altium, a PCB design software, on the Windows machine M2.
With Altium I am going to design the triple resonant circuit for the broadband EOM.
We found that two of three PZT mirrors are at wrong place in the chambers.
Therefore we have to move these PZT mirrors together with their connections.
Here is a diagram for the current situation and the plan.
Basically mirror (A) must be associated to the output beam coming out from the SRM, but it was incorrectly put as a part of the input optics.
Similar to that, mirror (C) must belong to the input optics, but it is incorrectly being used as a part of OMC stuff.
Therefore we have to swap the positions of mirror (A) and mirror (C) as shown in the diagram above.
In addition to the mirror immigration, we also have to move their cables as well in order to keep the right functions.
We took a look at the length of the cables outside of the chambers in order to check if they are long enough or not.
And we found that the cables from c1asc (green line in the diagram) is not long enough, so we will put an extension D-sub cable.
ETMU07 had its wire winched to the correct height, was balanced, standoff glued. Can be ready for going into the oven tomorrow, if an oven is available. (One of Bob's ovens has a leak, so he's down an oven, which puts everything behind schedule. We may not be able to get anything into the oven until Monday).
ETMU05 had magnets glued to the optic. Hopefully tomorrow we will winch the wire and balance the optic, and glue the standoff, and be ready to go into the oven on Monday.
The spring plungers were sonicated, but have not yet been baked. I told Daphen that we'd like the optics baked first, so that we can get ETMX in the chamber ASAP, and then the spring plungers as soon as possible so that we can install ETMY and put the OSEMs in.
I created a new setup script for the newest build of the gds tools (DTT, foton, etc), located in /opt/apps (which is a soft link from /cvs/cds/apps) called gds-env.csh.
This script is now sourced by cshrc.40m for linux 64 bit machines. In addition, the control room machines have a soft link in the /opt directory to the /cvs/cds/apps directory.
So now when you type dtt or foton, it will bring up the Centos compiled code Alex copied over from Hanford last month.
Joe showed me what was what with adding DAQ channels, and I have begun building a simulink model to acquire the PEM channels.
My models is in: /cvs/cds/rtcds/caltech/c1/core/advLigoRTS/src/epics/simLink/c1pem.mdl
Next on the to do list in this category: test which input connector goes with which channel (hopefully it's linear, exactly as one would think), and give the channels appropriate names.
The last time(Friday) I made an arrangement for RF distribution unit.
I am making RF distribution unit for RF upgrade which is designed by Alberto.
To reduce a noise from loose connection,
I tried to make the number of hard connect as much as possible while reducing the number of connection via wire.
This is why I put splitters right next to the front pannel so that the connection between pannel plugs and splitters could be made of hard joints.
I attached the arrangement that I made on the last Friday.
Next time, I will drill the teflon(the supporting plate) for assembly.
Any suggestion would be really appreciated.
I cleaned up the /cvs/cds/caltech/target/ directory of all the random models we had built over the last year, in preparation for the move of the old /cvs/cds/caltech/target slow control machine code into the new /opt/rtcds/caltech/c1/target directories.
I basically deleted all the directories generated by the RCG code that were put there, including things like c1tst, c1tstepics, c1x00, c1x00epics, and so forth. Pre-RCG era code was left untouched.
Front ends seem to be experiencing a timing issue. I can visibly see a difference in the GPS time ticks between models running on c1ioo and c1sus.
In addition, the fb is reporting a 0x2bad to all front ends. The 0x2000 means a mismatch in config files, but the 0xbad indicates an out of sync problem between the front ends and the frame builder.
As there are plans to work on the optic tables today and suspension damping is needed, we are holding off on working on the problem until this afternoon/evening, since suspensions are still damping. It does mean the RFM connections are not available.
At that point I'd like to do a reboot of the front ends and framebuilder and see if they come back up in sync or not.
- The tanks are open
[done] - Remove the PZT cable currently underlying between BS and ITMY chambers
[done] - Put this PZT cable between BS and IMC chambers. Connect it on the PZT on the IMC table (SM1)
[done]- Put the two OSEM cables between BS and ITMY chambers. Connect this cable to SRM.
The connector for this cable at the BS side is coming from Bob's place on Wednesday. We left it disconnected for now.
- Energize all of four PZTs and check the functionality.
So I started fully characterizing the beat detection path.
As a part of the characterization works, I measured the spectra of the RFPD noise as well.
The noise is totally dominated by that of the RFPD (i.e. not by an RF amplifier).
I am going to check the noise curve by comparing with a LISO model (or a simple analytical model) in order to make sure the noise is reasonable.
The red curve represents the dark noise of the RFPD, which is amplified by a low noise amp, ZFL-1000LN.
The blue curve is a noise of only ZFL-1000LN with a 50 Ohm terminator at its input.
The last curve is noise of the network analyzer AG4395A itself.
It is clear that the noise is dominated by that of RFPD. It has a broad hill around 100MHz and a spike at 16MHz.
Gain of ZFL-1000LN = 25.5 dB (measured)
Applied voltage to ZFL-1000LN = +15.0 V
Bias voltage on PD = -150 V
I measured the RF transimpedance of the POX photodiode by measuring the optical transfer function with the AM laser and by measuring the shot noise with a light bulb. The plots of these measurements are at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/POX.
I measured the noise of the photodiode at 11 MHz for different light intensities using an Agilent 4395a. The noise of a 50 ohm resistor as measured by this spectrum analyzer is 10.6 nV/rtHz. I fit this noise data to the shot noise formula to find the RF transimpedance at 11 MHz to be (2.42 ± 0.08) kΩ. The RF transimpedance at 11 MHz as measured by the transfer function is 6.4 kΩ.
As I said in the past entry (see this entry), there was unknown loss of about 20dB in the beat detection path.
Today I measured the frequency response of the wideband RFPD using the Jenne Laser.
Since all the data were taken by using a 1064nm laser, the absolute magnitudes [V/W] for 532nm are not calibrated yet.
I will calibrate the absolute values with a green laser which has a known power.
The data were taken by changing the bias voltage from -150V to 0V.
The shape of the transfer function looks quite similar to that Hartmut measured before (see the entry).
It has 100MHz bandwidth when the bias voltage is -150V, which is our normal operation point.
Theoretically the transfer function must keep flat at lower frequency down to DC.
Therefore for the calibration of this data, we can use the DC signal when a green beam with a known power is illuminating the PD.
I disconnected the yellow GPIB box from the backside of HP3563A (classic analyzer),
and connected it to AG4395A (network analyzer), which is the official place for it.
A story about minor disasters, and crises averted:
Once upon a time, in a cleanroom not so far away..... there lived an optic. To preserve anonymity, we shall call him "ETMU05". This optic had a rough day. When removing the grippers from the magnet-to-optic fixture, 4 out of 6 magnets broke off the dumbbells (the dumbbells were still securely glued to the optic...these had come out of the same batch that had problems last week, same problem). The remaining 2, LL and LR, were sadly of the same polarity. This is bad, because it means that the "humans" taking care of "ETMU05" didn't check the polarity of the face magnets properly, and ensure that they were laid out in an every-other pattern (LL and UR having the same polarity, and LR and UL having the opposite). So, the humans removed all magnets and dumbbells from ETMU05. All remaining glue was carefully scrubbed off the surfaces of ETMU05 using lens paper and acetone, and the magnets and dumbbells were sonicated in acetone, scrubbed with a lint-free wipe, sonicated again, and then scrubbed again to remove the glue. ETMU05 had a nice cleansing, and was drag wiped on both the AR and HR surfaces with acetone and iso. ETMU05 is now on vacation in a nice little foil hut.
His friend, (let's call him ETMU07) had a set of magnets (with polarities carefully confirmed) glued to him. The cleaned magnets and dumbbells removed from ETMU05 were reglued to their dumbbells, and should be dry by tomorrow.
.....And then they lived happily ever after. The End.
The revised schedule / status table:
c1iscex does not even see its 32 channel Binary output card. This means we have no control over the state of the analog whitening and dewhitening filters. The ADC, DAC, and the 1616 Binary Input/Output cards are recognized and working.
Tried recreating the IOP code from the known working c1x02 (from the c1sus front end), but that didn't help.
Checked seating of the card, but it seems correctly socketed and tightened down nicely with a screw.
Tomorrow will try moving cards around and see if there's an issue with the first slot, which the Binary Output card is in.
The ETMX is currently damping, including POS, PIT, YAW and SIDE degrees of freedom. However, the gds screen is showing a 0x2bad status for the c1scx front end (the IOP seems fine with a 0x0 status). So for the moment, I can't seem to bring up c1scx testpoints. I was able to do so earlier when I was testing the status of the binary outputs, so during one of the rebuilds, something broke. I may have to undo the SVN update and/or a change made by Alex today to allow for longer filter bank names beyond 19 characters.
The CDS oscillator part doesn't work inside subsystems.
Rolf checked in an older version of the CDS oscillator which includes an input (which you just connect to a ground). This makes the parser work properly so you can build with the oscillator in a subsystem.
So I did an SVN checkout and confirmed that the custom changes we have here were not overwritten.
Turns out the latest svn version requires new locations for certain codes, such as EPICS installs. I reverted back to version 2160, which is just before the new EPICs and other rtapps directory locations, but late enough to pick up the temporary fix to the CDS oscillator part.
1) Investigate ETMX SD sensor problems
2) Fully check out the ETMX suspension and get that to a "green" state.
3) Look into cleaning up target directories (merge old target directory into the current target directory) and update all the slow machines for the new code location.
4) Clean up GDS apps directory (create link to opt/apps on all front end machines).
5) Get Rana his SENSOR, PERROR, etc channels.
3) Install LSC IO chassis and necessary cabling/fibers.
4) Get LSC computer talking to its remote IO chassis
5) If time, connect and start debugging Dolphin connection between LSC and SUS machines
I've updated the Computer Restart Procedures page in the wiki with the latest fb restart procedure.
To just restart just the daqd (frame builder) process, do:
1) telnet fb 8088
The init process will take care of the rest and restart daqd automatically.
- Check the wiring after SOS Coil Driver Module and circuit around SDSEN
- Check whitening and dewhitening filters. We connected a binary output cable, but didn't checked them yet.
- Make a script for step 2
- Activate new DAQ channels for ETMX (what is the current new fresh up-to-date latest fb restart procedure?)
(Koji, Joe, Yuta)
We wanted to know more about CDS.
Same as in elog #3829.
What we did:
1. Made test RT models c1tst and c1nio for c1iscex.
c1tst has only 2 filter module(minimum limit of a model), 2 inputs, 2 outputs and it runs with IOP c1x01.
c1nio is the same as c1tst except it runs(or, should run) without IOP.
2. Measured the time delay of ADC through DAC using different machine, different sampling rate by measuring transfer functions.
3. c1nio(without IOP) didn't seem to be running correctly and we couldn't measure the TF.
"1 PPS" error appeared in GDS screen(C1:FEC-39_TIME_ERR).
It looks like c1nio is receiving the signal as we could see in the MEDM screen, but the signal doesn't come out from the DAC.
TF we expected:
All the filters and gains are set to 1.
We have DA's TF when putting 64K signal out to analog world.
D(f)=exp(-i*pi*f*Ts)*sin(pi*f*Ts)/(pi*f*Ts) (Ts: sample time)
We have AA filter and AI filter when downsampling and upsampling.
Coefficients can be found in /cvs/cds/rtcds/caltech/c1/core/advLigoRTS/src/fe/controller.c.
/* Coeffs for the 2x downsampling (32K system) filter */
static double feCoeff2x =
-1.25687596603711, 0.57946661417301, 0.00000415782507, 1.00000000000000,
-0.79382359542546, 0.88797791037820, 1.29081406322442, 1.00000000000000};
/* Coeffs for the 4x downsampling (16K system) filter */
static double feCoeff4x =
-1.71662585474518, 0.78495484219691, -1.41346289716898, 0.99893884152400,
-1.68385964238855, 0.93734519457266, 0.00000127375260, 0.99819981588176};
For 64K system, we expect H=1.
We also have a delay.
S(f)=exp(-i*2*pi*f*dt) (dt: delay time)
So, total TF we expect is;
a is a constant depending on the range of ADC and DAC(I think). Currently, a=1/4.
We may need to think about TF when upsampling.(D(f) is TF of upsampling 64K to analog)
Example plot is attached.
For other plots and the raw data, see /cvs/cds/caltech/users/yuta/scripts/CDSdelay2/ directory.
As you can see, TFs are slightly different from what we expect.
They show ripple we don't understand at near cut off frequency.
If we ignore the ripple, here is the result of delay time at each condition;
data file host FE IOP rate sample time delay delay/Ts
c1rms16K.dat c1sus c1rms adcSlave 16K 61.0usec 110.4usec 1.8
c1scx16K.dat c1iscex c1scx adcSlave 16K 61.0usec 85.5usec 1.4
c1tst16K.dat c1iscex c1tst adcSlave 16K 61.0usec 84.3usec 1.4
c1tst32K.dat c1iscex c1tst adcSlave 32K 30.5usec 53.7usec 1.8
c1tst64K.dat c1iscex c1tst adcSlave 64K 15.3usec 38.4usec 2.5
The delay time shown above does not include the delay of DA. To include, add 7.6usec(Ts/2).
- delay time is different for different machine
- number of filters (c1scx has full of filters for ETMX suspension, c1tst has only 2) doen't seem to effect much to delay time
- higher the sampling rate, larger the (delay time)/(sample time) ratio
- figure out how to run a model without IOP
- where do the ripples come from?
- why we didn't see significant ripple at previous measurement on c1sus?
(Suresh, Koji, Yuta)
No AWG. No tdssine.
What we did:
1. Added 2 LOCKINs for c1sus model.
Currently, we cannot put cdsOsc in a subsystem.
So, we put LOCKINs just for BS for a test.
The signal going into LOCKIN can be anything. For now, we just put a matrix for selecting the signal and connected the input signals to the ground.
See the following page for the current simlink diagram of c1sus model.
2. Edited MEDM screens. (see Attachment #1)
We succeeded in putting 2 LOCKINs and exciting BS.
During the update, we might destroyed things. For example, fb status is red in GDS screens.
We will wait for Joe to fix them.
- Fix cdsOsc and put LOCKINs for all the other optics
- Come up with a good idea what to do with this LOCKIN. Remember, LOCKIN is not just a replacement for excitation points.
- Enhance an oscillator so that we can put a random noise
If you come up with a good idea and want to add new things to current RT model;
1. Go to simLink directory and open matlab;
2. In matlab command line, type;
3. Open a model you want to edit.
4. Edit! CDS_PARTS has useful CDS parts.
There are some traps. For example, you cannot put cdsOsc in a subsystem
5. Compile your new model. See my elog #3787.
6. If you want to burt restore things;
7. Edit MEDM screens
8. Useful wiki page on making a new suspension MEDM screens;
I examined the magnet-dumbbell joints under the microscope to see whether the glue that I applied yesterday was sufficient or in excess.
I think the pictures below speak for themselves !
During the gluing process the Al dumbbell stays below and the magnet with a drop of glue on the lower face is placed on it and held in the teflon fixture. As seen in the pics the glue seems to have run up the surface of the magnet and has not collected in the narrow part of the dumbell. So it has climbed up along the narrow gaps between the magnet and the teflon fixture by capillary action. The glue stops where the teflon fixture ends, a little before reaching the free end of the magnet, which further indicates the capillary action.
c1iscex machine is currently being setup and RT model c1scx is running.
But ETMX(south) didn't seem to be damped, so I checked it.
What I did:
1. Checked the wiring. It seemed to be OK.
Looked LEMO monitor output of SUS PD Whitening Board(D000210) with oscilloscope and they seemed to be getting some sensor signal except SDSEN.
SDSEN is funny. C1:SUS-ETMX_SPDMon decreases slowly when PD input cable is disconnected, and increases slowly when connected.
There might be some problem in the circuits.
Looked LEMO monitor output of SOS Coil Driver Module(D010001) with oscilloscope and they seemed to be receiving correct signal from DAC.
When ULCOIL offset is added, ch1 increased and so on.
2. Checked the direction of SUSDOF motion when kicked with one coil.
The result was;
This table tells you, when ULCOIL_OFFSET increases, SUSPOS increases and so on.
If URCOIL and LLCOIL are swapped, they look correct.
Also, they have opposite sign to the usual optics(e.g. MCs, BS, PRM).
3. Changed TO_COIL matrix according to the table above(see Attachment #1). Changed signs of XXCOIL_GAINs.
4. ETMX damped!
- Check the wiring after SOS Coil Driver Module and circuit around SDSEN
- Check whitening and dewhitening filters. We connected a binary output cable, but didn't checked them yet.
- Make a script for step 2
- Activate new DAQ channels for ETMX (what is the current new fresh up-to-date latest fb restart procedure?)
Suresh and I glued the intact-from-the-first-round magnets to ETMU05. I accidentally got too much glue on one of the dumbbells (the glue was connecting the dumbbell to the gripper - bad news if we let that dry), and while I was cleaning it, the magnet broke off. So I used one of the ones that Suresh had re-glued last night, and he is putting that one back together after some cleaning.
To set the fixture, Suresh had the great idea of using small pieces of foil underneath the teflon pads to set the height of the optic in the fixture. The optic still rests on the teflon pads, but with the foil we have finer control over how the optic sits. Neat. Since both ETMs are the same, we shouldn't have to do any more adjustment for the other ETM.
The updated Status Table:
RF Transimpedance of 200Ohm means the residual impedance at the resonance (R_res) of 40,
if you consider the amplifier gain (G_amp) of 10 and the voltage division by the 50Ohm termination,
this corresponds to the thermal noise level of Sqrt(4 kB T R_res)*G_amp/2 = 4nV/rtHz at the analyzer, while you observed 35nV/rtHz.
35nV/rtHz corresponds to 7nV/rtHz for the input noise of the preamp. That sounds too big if you consider the voltage noise of opamp MAX4107 that is 0.75nV/rtHz.
What is the measurement noise level of the RF analyzer?
[Koji, Rana, and Kevin]
I have been trying to measure the shot noise of REFL55 by shining a light bulb on the photodiode and measuring the noise with a spectrum analyzer. The measured dark noise of REFL55 is 35 nV/rtHz. I have been able to get 4 mA of DC current on the photodiode but have not been able to see any shot noise.
I previously measured the RF transimpedance of REFL55 by simultaneously measuring the transfer functions of REFL55 and a new focus 1611 photodiode with light from an AM laser. By combining these two transfer functions I calculated that the RF transimpedance at 55 MHz is ~ 200 ohms. With this transimpedance the shot noise at 4 mA is only ~ 7 nV/rtHz and would not be detectable above the dark noise.
The value of 200 ohms for the transimpedance seems low but it agrees with Alberto's previous measurements. By modeling the photodiode circuit as an RLC circuit at resonance with the approximate values of REFL55 (a photodiode capacitance of 100 pF and resistance of 10 ohms and an inductance of 40 nH), I calculated that the transimpedance should be ~ 230 ohms at 55 MHz. Doing the same analysis for the values of REFL11 shows that the transimpedance at 11 MHz should be ~ 2100 ohms. A more careful analysis should include the notch filters but this should be approximately correct at resonance and suggests that the 200 ohm measurement is correct for the current REFL55 circuit.
c1iscex did not have test points working last night.
The diag -i command indicated that :
awg 19 0 192.168.113.80 822095891 1 192.168.113.80
awg 45 0 192.168.113.80 822095917 1 192.168.113.80
The first number after the awg should be the DCUID number. The IP address 192.168.113.80 corresponds to c1iscex. So we had awg and testpoints setup for DCUI 19 and 45 on c1iscex. DCUID 19 is c1x01 (the IOP), but 45 was used for a test awhile back.
Turns out that in the testpoint.par file located in /cvs/cds/rtcds/caltech/c1/target/gds/param, there were two entries for c1scx, one with DCUID 24 and also DCUID 45. The model at the time was running with DCUID 24.
So I changed the model DCUID to 45, deleted the [C-node24] entry in the testpoint.par file, and restarted the machine, and also did a "telnet fb 8088" and "shutdown" to restart the frame builder.
To clean the glue off the magnets and dumbbells I soaked them in Acetone for about an hour and then scrubbed the ends clean with a lint free tissue soaked in Acetone.
I then examined the ends under a microscope and found that while the flat faces were clean some of the grooves were still filled with glue.
While examining the magnets I found some small magnetic fibers stuck to the magnets. Rana had mentioned these before as potential trouble makers which could degrade the high frequency performance of the OSEMs.
To try and get the glue out of the grooves I put the dumbells through an ultrasonic bath for ten mins. Most of the glue has been removed from the grooves. Pics below
I proceeded try and recover the lost time by sticking the magnets back to the dumbbells. Increased the quantity of the glue to a slightly larger amount than usual. It should definitely squish out a bit now. We will know tomorrow when we open the gluing fixture.