This is not such a bad base design, but remember that we have to get a couple of parts with the purple anodize to see if there is a difference between black and purple in terms of the 532 nm reflectivity.
This was the error today:
GET /40m/ HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:18.104.22.168) Gecko/20100401 Firefox/3.6.3
Cookie: elmode=threaded; __utma=65601905.411937803.1291369887.1291369887.1291369887.1; __utmz=65601905.1291369887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SITESERVER=ID=4981c5fd42ae53c9c9e0980f2072be4f
I came in today to check up on the StripTool and burn the Ubuntu LTS (new CDS OS) DVD. I was pretty excited to see the PRM flashes on Mon1.
I waggled the PRM/BS alignments and got a good contrast MICH and then bright flashes in the PRM that totally overload Mon1's CCD.
Now I can see flashes of some IR junk in the X Arm; its way off on the left edge of the mirror, but there's a beam.
For the short term, we can hook up the IO PZTs to some old EPICS channels (like one of the AUX guys in the LSC area), but eventually it has to get hooked up to the new ASC or ASS. We have to bug Joe to see where this shows up in his master diagram.
**Note: if you get lost sometimes when doing the alignments, remember that you can use time_machine_conlog.
rossa:general>./time_machine_conlog 2010/12/31,11:00:00 PDT C1:SUS-ITMX_PIT_COMM
Issuing the conlog command:
/cvs/cds/caltech/conlog/bin/conlog +epics -interp at 2010/12/31,11:00:00 PDT "C1:SUS-ITMX_PIT_COMM"
LIGO controls: values at 2010 12/31 11:00:00 pst
Attached is the last 8 days of Vacuum Pressure trend which includes the pumpdown.
The crontab for op340m which runs various IFO maintenance activities has been set to the wrong path for the watchdog rampdown script since the CDS changeover.
This is a dangerous situation. With the watchdog thresholds set as high as 1000, the magnets can be broken if the new CDS has some mental problems. This kind of thing happened before at LHO (which is why Stan invented the watchdogs). Please try to make sure that the watchdog thresholds are not set that way - its our only defense against bad CDS.
I've now corrected the crontab. The watchdog thresholds are being stepped down every 30 minutes as before.
However, out test points are gone again, so who knows how things are behaving.
I found that there was no PEM data nor any other data (no SUS or otherwise. No testpoints, no DAQ).
I went through the procedure that Jenne has detailed in the Wiki but it didn't work.
1) Firstly, the 'telnet fb 8088' step doesn't work. It says "Connected to fb.martian" but then just hangs. To replicate the effect of this step I tried ssh'ing to fb and doing a 'pkill daqd'. That works to restart the daqd process.
2) The wiki instructions had a problem. In the GUI step, it should say 'Save' after the Acquire bit has been set to 1. Even so, this works to get the .ini file right and the DTT can see the correct channel list, but none of the channels are available. There are just 'Unable to obtain measurement data'.
3) I tried running 'startc1pem', but no luck. I also tried rebooting c1sus from the command line. That worked so far as to come back up with all the right processes running, but still no data. The actual /frames directory shows that there are frames, but we just can't see the data. I also tried to get data usind the DTT-NDS2 method, but still no luck. (*** ITMX and ITMY both came back with all their filters off; worth checking if their BURTs are working correctly.)
Using DataViewer, however, I AM able to see the data (although the channel name is RED). In fact, I am able to see the trend data ever since I changed the Acquire bit to 1. Plot attached as evidence. Why does DTT not work anymore???
Since Leo was trying to demo his LIGO Data Listener code, he noticed that there was and NDS2 issue. The NDS2 guy (JZ) noticed that the FrameBuilder had an issue.
We investigated. At 4PM on Dec 31, the GPS timestamp of the frame file names started to be recorded wrong. In fact, it started to give it a file name matching the correct time from 1 year in the past.
So that's our version of the Y2011 bug. Here's the 'ls' of /frames/full:
drwxr-xr-x 2 controls controls 252K Dec 26 03:59 9773
drwxr-xr-x 2 controls controls 260K Dec 27 07:46 9774
drwxr-xr-x 2 controls controls 256K Dec 28 11:33 9775
drwxr-xr-x 2 controls controls 252K Dec 29 15:19 9776
drwxr-xr-x 2 controls controls 244K Dec 30 19:06 9777
drwxr-xr-x 2 controls controls 188K Dec 31 16:00 9778
drwxr-xr-x 2 controls controls 148K Jan 1 08:53 9463
drwxr-xr-x 2 controls controls 260K Jan 2 12:39 9464
drwxr-xr-x 2 controls controls 252K Jan 3 16:26 9465
drwxr-xr-x 2 controls controls 248K Jan 4 20:13 9466
drwxr-xr-x 2 controls controls 36K Jan 5 00:22 9467
controls@fb /frames/full $
The culprit is the directory who's name starts out as 9463 whereas it should be 9779.
Just a proof that the DAQ is working - ran DTT on nodus from 3 hours ago.
Pretty fancy work actually...I wouldn't have guessed that you need to look at the back of the ETM. Does this mean that we can't see the flashes from inside the arm cavity? If so, its a pretty remarkeable statement about the wide angle scatter of the new mirrors. Do we really have 1W going into the MC?
I started reverting Megatron into a standard Ubuntu workstation after Joe/Osamu's attempt to steal it for their real time mumbo jumbo.
First, I installed a hard drive that was sitting around on top of it. That whole area is still a mess; I'm not surprised that we have so many CDS problems in such a chaotic state. There's another drive sitting around there called 'RT Linux' which I didn't use yet.
Second, I removed the ethernet cables and installed a monitor/keyboard/mouse on it.
Then I popped in the Ubuntu 10.04 LTS DVD, wiped the existing CentOS install and started the standard graphical installation of Ubuntu.
Megatron's specs attached:
There's, as usual, a disconnect between the real martian host table and the one displayed on the Wiki. Basically, the point is: DO NOT TRUST THE WIKI, because people who update the actual host table only randomly update the wiki table.
The only thing worth trusting is the file
on linux 1.
You will need to have 'root' or 'sudo' to get into that directory to read the file.
I ramped the PMC gain slider to find where it oscillates. It starts going bad at ~13 dB, so the new default gain is 7 dB to give us some margin for alignment improvements, etc.
I also fixed the TIME field in our MEDM screens by adding the following text to the C1IFO_STATE.db file which runs on c1iscaux:
field(DESC, "Current time and date")
field(DTYP, "EPICS IOC VAR")
field(SCAN, "1 second")
field(DESC, "Current time and date")
field(DTYP, "EPICS IOC VAR")
field(SCAN, "1 second")
This gets the time info from the c1ioo processor via channel access and gives it these mroe reasonable names. The first record is for backwards compatibility. The second record is a better name and we should use it in the future for all new screens. I had to reboot c1iscaux several times to figure out the right syntax, but its OK now. You have to reopen stale screens to get the field to refresh.
field(DESC, "Current time and date")
field(DTYP, "EPICS IOC VAR")
field(SCAN, "1 second")
field(DESC, "Current time and date")
field(DTYP, "EPICS IOC VAR")
field(SCAN, "1 second")
This avoids the previous idea of changing all of the MEDM screens.
Actually, I just found out that there are different flavors of 'YAG-444'.
There's a YAG-444AH and also a YAG-444-4AH. I'm not sure which one we have or even which is better. The diode's internal resistance is not listed.
They also say explicitly that he 'YAG Enhancement' is just using thicker Silicon. Since the absorption of 1064 nm light in Silicon is very small, most of the light just goes in and then comes back out without depositing much of the power.
I like this activateDAQ script, but someone (Jenne with Joe's help) still needs to add the PEM channels - we still cannot see any seismic trends.
I installed NTPD on Megatron (its Ubuntu, so different from the CentOS workstations). Here's the terminal cap to show that its actually working:
megatron:/etc>sudo /etc/init.d/ntp restart
* Stopping NTP server ntpd [ OK ]
* Starting NTP server ntpd [ OK ]
* NTP server is running
remote refid st t when poll reach delay offset jitter
nodus.martian 22.214.171.124 2 u 7 64 1 0.217 3.833 0.001
europium.canoni 126.96.36.199 2 u 6 64 1 155.354 3.241 0.001
Mon Jan 17 04:07:08 PST 2011
Along the way, I also updated the /etc/inet/ntp.conf file for nodus. It was using the USNO as a NTP server and I've pointed it to the Caltech NTP server as per the IMSS NTP page.
I used 50 mA to drive the laser diode. The light is split 50/50 between the DUT (Device Under Test) and the New Focus 1611 (1 GHz BW) diode used as the reference.
This measurement is the TF of DUT/(New Focus). The resonances are there, but clearly there's an issue with instability around 200 MHz. The setup is still powered up, so please be careful around the RFPD testing table (don't stomp around yank the cables out of the power supplies).
I looked at the RF Photodiode wiki that Alberto has started - most of the TF features are replicated there. Todo:
* Update the 'schematic' with a real schematic instead of the cartoon.
* Change the circuit to remove the resistor in the RF path.
* Add compensation to avoid the 200 MHz instability.
* Make sure to include opamp current noise in the noise model (it is the dominant noise source but has been left out in the noise estimation plot).
* Make the output into a true 50 Ohms.
I found this old plot in an old elog entry of Osamu's (original link).
It gives us the differential displacement noise of the arms. This was made several months after we discovered how the STACIS made the low frequency noise bad, so I believe it is useful to use this to estimate the displacement noise of the arm cavity today. There are no significant seismic changes. The change of the suspension and the damping electronics may produce some changes around 1 Hz, but these will be dwarfed by the non-stationarity of the seismic noise.
The DAQ Wiki pages say to use port 8088 for restarting the Frame Builder. I tried this to no avail.
op440m:daq>telnet fb 8088Trying 192.168.113.202...Connected to fb.martian.Escape character is '^]'.^]telnet> quitConnection to fb.martian closed.op440m:daq>telnet fb 8087Trying 192.168.113.202...Connected to fb.martian.Escape character is '^]'.daqd> shutdownOKConnection to fb.martian closed by foreign host.
Apparently, 8087 is the right port. Various elog entries from Joe and Kiwamu say 8087 or 8088. Not sure what's going on here.
After figuring this out, I activated the C1:GCV-XARM_COARSE_OUT_DAQ and C1:GCV-XARM_FINE_OUT_DAQ and set both of them to be recorded at 2048 Hz. We are loading filters and setting gains into these filter modules such that the OUT signals will be calibrated into Hz (that's why we used the OUT instead of the IN1 as there was last night).
We've set up a beat note measurement between the VCO driver and the Marconi (see Suresh's elog).
Here's the 'unWhiten' filter for compensating the SR560 TF.
It has poles = 1 mHz, 5 kHz, 5 kHz
and zeros = 30 mHz, 1 kHz
The gain is set to be ~0.001 in the 1-100 Hz band to compensate the G=1000 of the SR560.
But the PLL seems very fishy to me. The ZP-3MH needs 13 dBm to operate correctly. You should change the MODLEVEL input of the VCO so as to make the LO input of the mixer go up to 13 dBm. Then the input from the PD should be ~0 dBm.
Also, the PLL diagram seems to show that you have a 1/f^2 loop: 1/f from the SR560 and 1/f from the Hz->rad conversion ??
That's some pretty fast work! I thought we would be taking up to a week to get that happening. I wonder what's the right way to measure the inherent frequency noise of this thing?
Also, should the comparator part have some hysteresis (ala Schmidt trigger) or is it best to just let it twirl as is? Is it sensitive to DC offsets on the input or is there a high pass filter? What's the correct low pass filter to use here so that we can have a low phase lag feedback to the ETM?
Tonight we noticed that there were significant improvements to be had in the predicted DARM Wiener filtering FF performance by using weighting filters and more taps in the FIR filter.
The plots below tell the story:
The first one shows the improvement in the residual (black & blue) by applying a weighting filter. The weight filter tilts the spectrum up at HF and applies and all real pole BP from 10-20 Hz.
The second plot shows the improvement gotten by using 3000 instead of 2000 taps for the Wiener filter. With the larger number of taps we not only get the big improvement at LF, but also some beefy reduction in the higher frequency stack modes and the LOS roll mode.
I'm not sure why we haven't run across this before; the weighting filter was arrived at today by just iterating by hand on the placement of poles and zeros until the trace looked nice.
Jenne is going to run this new filter on the S5-month that we have been using for stationarity testing.
* Some notes:
** this Wiener stuff is faster, by far, on rossa than either megatron or rosalba or my laptop. More than a factor of 3.
*** there is a bug with Macports/Matlab - if you get fftw3 with Macports, it sets itself as the right version to use. This confuses matlab in some cases.
if you get the error about libfftw3.dylib, whe trying fft in matlab after installing macports, then you can fix it by setting the Matlab lib/ path with the fftw libraries to be ahead of /opt/local/lib in the LD_LIBRARY_PATH in your .cshrc.
I removed the rsync backup from nodus' crontab temporarily so as to not have multiple backup jobs running. The job I started from yesterday was still running. Hopefully the backup will finish by Monday.
The line I removed was:
0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup
I swapped over to a 3x longer cable (old 65 ft. Pasternak cable from ancient 40m days). The old one was 6m, the new one is 18.2 m. It was already coiled up so I put it into a tupperware box to shield it somewhat from the HVAC wind.
The noise went down nearly proportional to the length (after I recalibrated the DAQ channel for the ~3x higher phase->voltage gain). With this length, the peak-peak mixer range is 5.5 MHz, so still enough to go an FSR here.
I give credit to the low frequency improvement entirely to Tupperware for their excellent containers. The current noise limit is most likely the SR560.
I noticed that the RMTEMP channel was spiking myteriously when Kiwamu opened the PSL door. We found out that the LEMO connectors would intermittently short to the case and cause ~1 deg steps in the temeprature.
We have removed the case and examined it. Not only were the connections to the box intermittent, there was a cold solder joint inside on an unsecured flying add-on opamp. The whole thing is a giant hack.
PK was the last person to work on this box, but I'm sure that he wouldn't have left it in this state. Must be gremlins.
The LEMO connectors on the front are the ones touching. The LT1021 is the badly soldered part.
375 mW is way too much light. We must never put more than 100 mW on any of these diodes. We don't want to blow up more diodes like we did with the WFS. The InGaAs diodes often show an excess dark noise before they finally let go and completely fail. This one may show excess during the shot noise testing.
We should ensure that the beam paths are engineered so that none of these new detectors ever sees such high light levels.
The DC path should be made to let us see a 10V from the differential EPICS readout when there is 100 mA of photocurrent (i.e. an effective 100 Ohms transimpedance):
0.1 A * 10 V/A * 5 V/V * 2V/V
The last factor of 2 is from the single to differential conversion.
If we really only get 15 mV from 375 mW, then this diode or the circuit is broken.
This is just a listing of CDS problems I still notice today:
MC2-MCL button was left ON due to BURT failure. This, of course, screws up our Green locking investigations because of the unintended feedback. Please fix the BURT/button issue.
Although Joe and Kiwamu claim that they have inserted the correct DAQ names for the OPLEVs (e.g. PERROR and YERROR) back in Jan. 11, when I look today, I see that these channels are missing!
All of the SUS used to have only 1 filter module for SIDE. They now have 3 filter modules for SIDE just like the other DOFs.
Today I moved the filters around so that the sensor filters are in SDSEN, the servo filters are in SUSSIDE, and the dewhitening for the coil is in SDCOIL.
I noticed along the way that the bounce/roll mode notches for all of the suspensions are still set for the frequencies of the previous suspensions. Suresh has 'volunteered' to find the new frequencies and make the new bandstop filters by looking up the seminal work on this by Dan Busby / Sam Waldman.
I forgot to elog that last night I touched up the MC2_TRANS QPD setup. I was perplexed by it always going out of alignment so I investigated.
I found that the fork clamp for the steering mirror for the QPD was not tightened. Shame. The beam diameter was equal to the aperture of the QPD and was clipping. Double shame.
I added a lens and tightened the mounts and centered the beam at ~9 PM yesterday. You can see in the attached trend that the measured power went up by ~10%.
Later, there's a big gap where Valera and Steve change out the PMC. You can see that the MC REFL voltage goes from 4.5 V to 5 V (10% increase in the power delivered to the MC).
There's essentially no change in the total transmission - this indicates that although the PMC transmission is now higher by ~10%, the matching to the IMC has been degraded by an equivalent fraction.
Needs some mode matching work.
This is the 140 ft. MFD measurement of the VCO phase noise. It is open loop and so should be a good measurement. The RMS is 30 Hz integrated down to 2 mHz.
I don't know why this doesn't agree with Suresh's measurements of the same thing which uses the PLL feedback method.
In BLUE, I also plot the frequency noise measured by using a Stanford DS345 30 MHz func. generator. I think that this is actually the noise of the FD (i.e. the SR560 preamp) and not the DS345. Mainly, it just tells you that the PINK VCO noise measurement is a real measurement.
I calibrated it by putting in a 5 kHz_pp triangle wave on the sweep of the DS345 and counting the counts in DV.
DTT stopped working for recent data. An 'ls' in the frames/full/ directory reveals:
drwxr-xr-x 2 controls controls 258048 Feb 3 12:26 9807
drwxr-xr-x 2 controls controls 258048 Feb 4 16:13 9808
drwxr-xr-x 2 controls controls 262144 Feb 5 19:59 9809
drwxr-xr-x 2 controls controls 258048 Feb 6 23:46 9810
drwxr-xr-x 2 controls controls 258048 Feb 8 03:33 9811
drwxr-xr-x 2 controls controls 262144 Feb 9 07:19 9812
drwxr-xr-x 2 controls controls 253952 Feb 10 11:06 9813
drwxr-xr-x 2 controls controls 266240 Feb 11 14:53 9814
drwxr-xr-x 2 controls controls 266240 Feb 12 18:39 9815
drwxr-xr-x 2 controls controls 266240 Feb 13 22:26 9816
drwxr-xr-x 2 controls controls 262144 Feb 15 02:13 9817
drwxr-xr-x 2 controls controls 253952 Feb 16 05:59 9818
drwxr-xr-x 2 controls controls 241664 Feb 17 09:46 9819
drwxr-xr-x 2 controls controls 28672 Feb 17 12:22 9820
drwxr-xr-x 2 controls controls 32768 Feb 17 15:06 6663
drwxr-xr-x 2 controls controls 73728 Feb 17 23:39 6664
controls@fb /frames/full $ date
Thu Feb 17 23:39:27 PST 2011
Frank put his low noise preamp info here.
I suggest that we build these (using Altium) but replace the cheapo transistors with the high class MAT03 matched BJT pair from Analog Devices.
This will allow us to have a pre-amp better matched to the noise of the mixers down to low frequency.
Looks like there was a mysterious loss of data overnight; since there's nothing in the elog I assume that its some kind of terrorism. I'm going to call Rolf to see if he can come in and work all night to help diagnose the issue.
When Koji and I were massaging the MC, we noticed that the oscillations were at 48.5 kHz. They were pretty huge and are probably what you're seeing on the beat. My guess is that they are the PZT resonances of the PSL 2W NPRO; we need to put a notch in the FSS box - it still has the notch from the old NPRO.
Its been well noted in the past that sweeping the PMC at high power leads to a distortion of the transmitted power curve. The explanation for this was coating absorption and thermo-elastic deformation of the front face of the mirrors.
Today, I did several sweeps of the PMC. I turned off its servo and tuned its PZT so that it was nearly resonating. Then I drove the NPRO via the HV driver (gain=15) with 0-150 V (its 1.1 MHz/V) to measure the PMC transmitted light. I adjusted the NPRO pump diode current from 2A on down to see if the curves have a power dependent width.
In the picasa web slideshow:
There are 3 significant differences between this measurement and the one by John linked above: its a new PMC (Rick says its the cleanest one around), the sweep is faster - since I'm using a scope instead of the ADC I feel free to drive the thing by ~70 MHz in one cycle. In principle, we could go faster, but I don't want to get into the region where we excite the PZT resonance. Doing ~100 MHz in ~30 ms should be OK. I think it may be that going this fast avoids some of the thermal distortion problems that John and others have seen in the past. On the next iteration, we should increase the modulation index for the 35.5 MHz sidebands so as to get a higher precision calibration of the sweep's range.
By eye I find that the FWHM from image #4 is 11 ms long. That corresponds to 300 mV on the input to the HV box and 15 V on the PZT and ~16.5 MHz of frequency shift. I think we expect a number more like 4-5 MHz; measurement suspicious.
There are 3 standard techniques to reduce this effect:
1) Stabilize the end laser by sensing the green light coming into the PSL before recombination and feeding back with SR560 (this is the only one that you should try at first).
2) Moving to the center of the MFD fringe via ETM steps.
3) Auto-alignment of the beam to the arm.
Ridiculous and hacky. Digital stabilization removed as well as the old "leave a pile of equipment on a stool" strategy.
We used a a BNC cable to send a pickoff of the beam before the recombination to the end via an SR560.
I did some work on the ETMY real and Sim.
It seems like there is still a problem with the input whitening filters. I believe the Xycom logic is set such that the analog whitening of the OSEM signals is turned ON only when the FM1 is turned OFF. Joe has got to fix this (and elog it) so that we can damp the suspension correctly. For now, the damping of the ETMY and the SETMY require different servo gains and signs, probably because of this.
Using 2 dBm for a Level 7 mixer is so bogus, that I will dismantle this as soon as I come over.
Its going to need some kind of way to locate the PMC on the top. In the previous design, we had the 3 balls to decouple the body from the base. That design was flawed due to the roughness of the holes in the PMC body.
Also probably need some kind of relief on the bottom. Its possible that it would be OK like this, but I am unsure if the shop can maintain the flatness we want over the whole length and/or the flatness of any given (OLD) optical table over ~8". Its probably not a good idea to have to torque this (aluminum?) to make it conform to the optical table's shape.
Ooh. Can you explain the purpose of the resistors which are connected to the (+) inputs? It looks like some real electronics ninjitsu.
I am a little concerned about using these low pass filters so close to the band edge. Recall that there is no on-board preamp for the RF input to the mixer.
So, if the input impedance of the filters is not 50 Ohms, we will get some unwanted reflections and sensitivity to cable length.
I think its worth while to check the impedance or S-parameters of these things with the LO activated to find out if we need to remove them or not.
One way to avoid some of the bad stuff in there is to take the 1 dBm input and amplify it to ~21 dBm before splitting and sending in to the Level 17 mixers.
One way to do this is by using the A3CP6025 from Teledyne-Cougar. Its an SMA connectorized amp which can put out 25 dBm and has a gain of 24 dB. We can just glue it onto the demod boards. Then we can remove the ERA-5 amplifiers and just use the broadband splitter as Kiwamu mentioned.
The performance plots for POX_11 in the wiki are horrendous and the schematic is missing.
I opened up the box and found all kinds of horrors. There were multiple tunable parts and a flurry of excess nonsense.
The top 2 worst offenders:
1) The main tunable inductor was busted. I removed it and found that the coil was open. Too much indelicate soldering in its vicinity had melted the wire. Someone had put extra inductors and capacitors around it to make it seem as if the PD was working fine, but the noise performance was off by a factor of ~100.
2) The MAX4107 had a 1.4k series resistor. This make the output go through a 1450/50 voltage division which is not nice for the SNR. I removed it.
I then struggled for awhile to get a sensible response. It turned out that the TEST IN input was not giving me a sensible TF. Jenne and I fired the Jenne laser at it and found that the 11 MHz main resonance is there. In the morning I'll finish this off and post more results. I think its going to end up being fine.
I used the Jenne AM laser to tune up the PD (used to be POX_11 but now is called REFL_11). In addition to the notch at 22 MHz, I have also put in a LC notch at 5*f = 55.3 MHz. The transfer function below shows the RF OUT of the PD v. the drive to the laser. I didn't divide out by the 1811 because its not on the EE bench.
I worked on AS_11 today. Its ready for its noise / optical gain calibrations. I have left it on Suresh's desk.
This was one of the 24.5 MHz Black Box (Ben Abbott) style RFPDs rescued from LLO. The tunable inductor that was installed was too small to get the frequency down to 11 MHz and so I swapped in one of the shielded, ferrite core ones from our '7mm' CoilCraft kit. It had a range of 1.2 - 1.8 uH according to the datasheet.
I wasn't able to simulataneously get the peak at 11.06 MHz and the notch at 59.3 MHz and so I took Koji's advice and tuned the peak best. The plot above shows how the notch is slightly off. I think its not a problem; to get it better we would have to change out the inductor for the "2-omega" notch, but I was too lazy. The thinking is that its more important to have the gain be symmetric around the signal readout frequency so as to not imbalance the audio sidebands.
Since this one is going to be AS_11, we think that the 22 MHz signal will be tiny: the transmission of the 11 MHz sidebands to the dark port is small. If we later want to put in a 22 MHz notch anyway, there is space to do this via the 'active notch' pads around the MAX4107.
For the above plot, I used the Jenne laser. The DC output of the PD was ~30 mV (~0.6 mA). The RF drive to the laser was -10 dBm: no saturations. I have calibrated out the cable responses, but not using the 1811 setup, so the absolute calibration has yet to be done.
Also, it needs some new stickers. It would be handy if someone can figure out how to get some sheets of stickers that we can put into the printer. Then we can laser printer all of the data onto the stickers and stick them to the RFPD box.
* Farfalla, a lab laptop, seems out of network.
If you look at the real host table instead of the misleading host table in the wiki, you will see that someone has deleted Farfalla from there. She needs to be re-added.
I found that the MC autolocker was OFF. Kiwamu says he turned it off because its slow. Suresh says that he has some feelings that maybe something is wrong. I'll let them describe what they know about the MC in an elog.
I checked the trend of the MC and PMC transmissions for the past 30 days:
Looks like the alignment has been drifitng. PMC was corrected recently by Koji, but the alignment of the input beam to the MC or the MC itself has to be fixed. Has someone been twiddling the MC SUS alignment biases??