After discussing with Koji, we looked at the aLIGO incarnation of this board. Interestingly, it too has a similar topology of 4 switchable gain stages with gains of 24, 12, 6 and 3dB. The main differences are that they use single Op27 ICs instead of the quad LT1125s, and also, they use a different combination of feedback resistors to realize the various gains.
We considered upping the feedback resistance (R15, R143) on the 24dB gain stage of our boards from (1k, 66.5ohms) to (3k, 200ohms) as on the aLIGO boards - but this doesn't really help? Because KCL demands that the same current flow in R15 and R143, and so the output Vsat of the op amp and its max current driving capabilities in combination determine if the inverting input can follow the non inverting input?
As Hartmut points out in his note, he was able to access the full range of ADC voltages when the gain was set to 3dB, despite the fact that the LT1125 was still getting internally saturated. Operating with minimum 24dB whitening gain doesn't really solve the problem either because the problem just gets shifted to the next gain stage in the chain, and we still have saturation. I also don't have a feeling for how much differential voltage these LT1125s can sustain before they are damaged - I guess the planned THD check will reveal if they are okay or not.
It seems to me like the only way to truly fix this problem of one stage saturating and screwing up the others is to use single Op27s (or equivalent) in place of the quad LT1125s. The aLIGO design also has a series resistance to the non-inverting input - this can help prevent current overdraw from the previous stage (due to a lowered input impedance of the OpAmp - but I wonder how low this can go?).
this is the note from Hartmut Grote on this topic from 2004
I plan to do some characterization of this problem. The plan is to use THD as a metric for whether we are having hidden saturations. Pg 9 of the LT1125 datasheet tells us what fraction of THD to expect. I will use one of the several unused DAC channels available at the LSC rack to drive a 100Hz sine wave into one of the inputs of the whitening chassis, and measure the THD up to a reasonable harmonic number (will probably be set by the ADC noise) for (i) various whitening gain settings and (ii) various input signal amplitudes.
The motivation is to attempt to quantify the problem better:
Then we can decide what, if anything, to do about this issue.
DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu. Basically, we can't measure any fast channels with DTT. I keep getting the error: "Unable to select testpoints." Sadface.
Similar things are true for DataViewer. The same limited number of fast channels, and no data found:
Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
Is this a framebuilder problem? Is this something that the CDS team has on the to-do list?
Test points for the SUS channels should be there. They have been working previously this week. Possibly break down points include awgtpman, mx_streams, and the fb itself. I'll look into that.
As far as other fast channels, there are no other fast front ends running than the suspensions ones we have. Until additional channels get connected to the front ends and the models updated, those are the channels we have available. However I am working on getting c1ioo up and running, and we can try connecting in some PEM channels today to the c1sus front end's 4th ADC.
I tried starting a fresh instance of the frame builder, but when I brought the old copy down, it left a pair of zombie or dead mx_stream processes running on c1sus . Basically c1mcs and c1rms were still running, while c1x02 and c1sus came down. I tried to kill the processes but this caused the c1sus machine to crash. In the past I've killed left over mx_stream processes running after the frame builder has gone down, but I've never seen them crash the computer. I'm unsure why this happened since we haven't done any updates of the code, just updated models and daq configuration files.
Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
When adding the ETMX DAQ channels using the daqconfig gui (located in /opt/rtcds/caltech/c1/scripts/) on C1SCX.ini, we forgot to set the acquire flag to 1 from 0.
So the frame builder was receiving the data, but not recording it.
We have since then added ETMX and the C1SCX.ini file to Yuta's useful "activateDAQ.py" script in /opt/rtcds/caltech/c1/chans/daq/, so that it now sets the sensor and SUSPOS like channels to be acquired at 2k when run. You still need to restart the frame builder (telnet fb 8087 and then shutdown) for these changes to take effect.
The script now also properly handles files which already have had channels activated, but not acquired.
The VEA laptop asia was configured to be able to connect to too many WiFi networks - it was getting conflicted in its default position at the vertex and trying to hop between networks, for some reason trying to connect to networks that had poor signal strength. I deleted all options from the known networks except 40MARS. Now the network connection seems much more stable and reliable.
The model of our martian wifi router (NETGEAR R6400) was found in the FBI router list to be rebooted asociated with the malware "VPNFilter" issue.
I checked the attached devices and found bunch of (legit) devices blocked to access the wifi router. This is not an immediate problem as most of the packets do not go through the wifi router. But potentially a problem in some cases like Wifi enables GPIB adapters. So I marked them to be "allowed".
In this opprtunity, I have updated the firmware of the wifi router and this naturally involved rebooting of the device.
I have measured a wideband response of the fast PZT in the LWE NPRO 700mW in the Alberto's setup.
This is a basic measurement to determine how much phase modulation we can obtain by actuating the fast PZT,
primarily for the green locking experiment.
1. Locked the PLL of for the PSL-NPRO beating at 20MHz.
2. Added the modulation signal to the NPRO PZT input.
I used the output of the network analyzer sweeping from 100kHz to 1MHz.
3. Measured the transfer function from the modulation input to the PLL error signal.
The PLL error is sensitive to the phase fluctuation of the laser. Found that the first resonance is at 200kHz.
The TF is not valid below 3kHz where the PLL suppresses the modulation.
4. Single frequency modulation: Disconnected the PLL setup.
Plug Marconi into the fast PZT input and modulate it at various frequencies.
Observing with the RF spectrum analyzer, I could see strong modulation below 1MHz.
It turned out later that the TF measurement missed the narrow peaks of the resonances due to the poor freq resolution.
Also the modulation depth varies frequency by frequency because of the resonances.
Scanned the frequency to have local maximum of the modulation depth. Adjusted the
modulation amplitude such that the carrier is suppressed (J0(m)=0 i.e. m~2.4). As I could not obtain
the carrier suppression at above 1MHz, the height of the carrier and the sidebands were measured.
The modulation frequency was swept from 100kHz to 10MHz.
5. Calibration. The TF measured has been calibrated using the modulation depth obtained at 100Hz,
where the resonance does not affect the response yet.
The responce of the PZT was ~10MHz/V below 30kHz. Looks not so strange although this valure is
little bit high from the spec (2MHz/V), and still higher than my previous experience at TAMA (5MHz/V).
Note that this calibration does not effect to the modulation depth of the single freq measurement as they are independent.
Wiener Filtering was applied on the data collected from the X-arm during the time: GPS time-996380715 (Aug 02, 2011. 21:25:00. PDT) to GPS time-996382215 (Aug 02, 2011. 21:50:00. PDT) for a duration of 1500 seconds. During this time the X-arm was locked, we checked it by acquiring data from channel C1:LSC-TRX_OUT_DQ .
The seismometers were near the beam splitter (guralp2) and near MC2 (guralp1).
Target data was obtained from channel C1:LSC-XARM_IN1_DQ.
Following graphs were obtained after applying the Wiener filter:
1.Seismic data acquired from Guralp1 (X and Y) and Guralp2 (X and Y) 2.Seismic data acquired from Guralp2 X 3.Seismic data acquired from Guralp2 Y
These graphs were obtained with srate = 2048 (sample rate) and N = 20000 (order of the filter).
Graph 1 is the best because the black (residual) line is below the red (target) line for low frequencies since we used seismic data from 4 channels. Graph 3 is the worst because we used seismic data from only one Y channel (Y axis of Guralp2) that is less related with the X-arm mirrors' motion since they are oriented orthogonally.
Tried the wiener filter with the TF from p.5900
Tried it out with the TFs from p.5900:
Adding a filter element that compensates the acutator TF makes the MC lose lock.
Quick update on my wiener filtering status:
Joe has been helping me get on the GRID, so I now have a grid certificate, and accounts on most/all of the clusters.
Joe also helped me get menkar to get S5 data so that I can do wiener filtering to the back-data.
I've been running the wiener filtering algorithm, and right now, it doesn't do anything to improve the DARM_CTRL data. I am confident that this is because something is funky in the wiener filtering algorithm somewhere. The indicator of this is that the wiener filtering calculation takes the same amount of time (~95 seconds) to calculate a filter for 64 seconds of data as for 1 hour of data (both for N = 2000 taps).
For reference, attached are my plots for the wiener filtering result for (1) 64 seconds of S5 data, and for (2) 3600 seconds of S5 data.
These plots were made using H1:DARM_CTRL as the signal to minimize, with 4 seismometers as the witness channels (EX_SEISX, EY_SEISY, LVEA_SEISX, LVEA_SEISY)
I'm working on figuring out what's going on with the filtering algorithm, and why it does work for C1:MC_L minimization, but does not work for H1:DARM_CTRL minimization.
I have put the Wiener filter scripts into /opt/rtcds/caltech/c1/scripts/Wiener/ . They are under version control.
The idea is that you should copy ParameterFile_Example.m into your own directory, and modify parameters at the top of the file, and then when you run that script, it will output fitted filters ready to go into Foton. (Obviously you must check before actually implementing them that you're happy with the efficacy and fits of the filters).
Things to be edited in the ParameterFile include:
I think that's everything that is required.
Since we are using Wiener filtering in our project, we studied the derivation of Wiener-Hopf equations. Whatever we understood we have written it as a pdf document which is attached below...
Over the weekend and today, the wifi was acting bad with frequent disconnections and no internet access. I tried to log into the web interface of the ASUS wifi but with no success.
I pushed the reset button for several seconds to restore factory settings. After that, I was able to log in. I did the automatic setup and defined the wifi passwords to be what they used to be.
Internet access was restored. I also unplugged and plugged back all the wifi extenders in the lab and moved the extender from the vertex inner wall to the outer wall of the lab close to the 1X3.
Now, there seems to be wifi reception both in X and Y arms (according to my android phone).
Ug, factory resets... Caltech IMSS announced that there was an intermittent network service due to maintenance between Sept 19 and 20. And there seemed some aftermath of it. Check out "Caltech IMSS"
I've added a new page in the wiki which describes the current naming scheme for the .mdl model files used for the real time code generator. Note, that these model names do not necessarily have to be the names of the channels contained within. Its still possible to make all suspension related channels start with C1:SUS- for example. I'm also allocating 1024 8 byte channels for shared memory address space for each controller and each simulated plant.
The wiki page is here
Name suggestions, other front end models that are needed long term (HEPI is listed for example, even though we don't have it here, since in the long run we'd like to port the simulated plant work to the sites) are all welcome.
I've set up the Wilcoxon accelerometers on the SP table for a huddle test, to estimate their noise levels.
They're clamped down to the table along the same axis, and their housings are in good contact, in hopes to make them as correlated as possible.
Steve helped me move the DAQ cables from under the BS/PRM oplev table, to dropping from the cable tray above the POX table, so I could get them plugged in at the SP table. This also helps reduce the rats nest by the access connector, and is a fine location for when the accelerometers are attached at MC1 & MC2.
A quick glance at DTT shows coherence of >0.9 from about 2-100Hz for all six. A three-corner-hat deal will provide an easy estimate of the noise floor of each one. If we feel like being fancy / accounting for possible gain differences, we could try some MISO wiener action, but that is probably overkill.
Here are some results for the 3-corner hat subtraction for the six accelerometers, from ~1 hour of data that didn't look to have any sharp features/glitches from human activity in the lab.
I used the python uncertainties package to try and get an estimate of the uncertainty in the subtracted noise floor, by taking into account every possible possible combination of 3 sensors and the fluctuations in the spectrograms of the subtracted signals. I've attached the python code if anyone is interested in the implementation.
I pulled out the accelerometer data sheets to read their slightly varying V/g calibration (which differs on the order of a few percent from unit to unit). This improved the subtraction factor from ~20 to over 100 at some frequencies. I've edited the filter modules such that the OUT_DQ channels are already calibrated into m/s^2.
To improve our sensor noise estimate, the ACC cables should be clamped using a rubber pad and a big dog clamp on the SP tabletop before exiting the table. Also the sensors themselves should be covered with a foam box or a double cardboard box. The high-frequency acoustic noise may limit the 10 Hz performance since piezos are not very linear.
I've set up the Wilcoxen accelerometers on the SP table for a huddle test, to estimate their noise levels.
Wilcoxon. Not Wilconox or Wilco or Wilcoxen. Have some pity on future keyword searchers.
Updated: On Thursday/Friday (sorry for late elog) I was messing with Eric's Wilcoxon 731A accelerometer huddle test data that was taken without the box and cables being adjusted properly. Anyways, I performed the three cornered hat analysis as he had done but I also performed a six cornered hat method as well instead of permuting around in pairs of three accelerometers. The following plots of the ASD's show the results,
It is interesting to note the improvement at low frequencies when six accelerometers are used instead of six while at higher frequencies we can clearly see how the results are worst than the three hat results.
I decided to take a mean of all six accelerometers measured ground signal as well as that for their computed selfnoises, this is plotted below,
Notice the obvious improvement along the entire frequency band of the measurements when all accelerometers are used in the data analysis.
I also performed some Wiener filtering of this data. There was an obvious improvement in the results,
The mean of the signals is also plotted below, just as I did with the cornered hat methods,
I also compared the mean self noise of the accelerometers against the manufacturers calculated selfnoise that Rana put up on Github. Both methods are compared against what the manufacturer claims,
As expected the measured noise curves of the Wilcoxon is not as good as what the manufactures stated. This should improve once we redo the huddle test with a better experimental setup. We have some pretty interesting results with the six cornered hat method at around 5 Hz, it is surprisingly accurate given how rough the calculations seemed to be.
I have attached my code for reference: code_accel.zipselfnoise_allsix.png
SEE attachments for better plots of the six accelerometers...
Eric and Steve,
We removed Wilcoxon Accelerometer PS and Amplifier unit under the BS optical tabel yesterday. The six cabels going to DAQ were labeled and left in place. Gain setting were 100, except channel 3 was 10.
The ~ 40 m long 2 sets of 3 cables were very happy to get their kinks out. Especially the set going just south of ITMX optical table.
We have to take better care of these cables! Your data will be useless this way.
[Kiwamu, Jenne, Alberto, Steve, Bob, Koji]
We finished wiping of four test masses without any trouble. ITMY looked little bit dusty, but not as much as ITMX did.
We confirmed the surface of the ITMX again as we worked at vertex a lot today. It still looked clean.
We closed the light doors. The suspensions are left free tonight in order to check their behavior.
Tomorrow morning from 9AM, we will replace the door to the heavy ones.
When Alberto was parting the Red Sea this morning, and turning it green, he noticed that the wireless had gone sketchy.
When I checked it out, the ethernet light was definitely blinking, indicating that it was getting signal. So this was not the usual case of bad cable/connector which is a known problem for our wireless (one of these days we should probably relay that ethernet cable....but not today). After power cycling and replugging the ethernet cable, the light for the 2.4GHz wireless was blinking, but the 5GHz wasn't. Since the wireless still wasn't working, I checked the advanced configuration settings, as described by Yoichi's wiki page: 40m Network Page
The settings had the 5GHz disabled, while Yoichi's screenshots of his settings showed it enabled. Immediately after enabling the 5GHz, I was able to use the laptop at Alberto's length measurement setup to get online. I don't know how the 5GHz got disabled, unless that happened during the power cycle (which I doubt, since no other settings were lost), but it's all better now.
After poking around for a few minutes several facts became clear:
1) At least one GPIB interface has a hard ethernet connection (and does not currently go through the wireless).
2) The wireless on the laptop works fine, since it can connect to the router.
3) The rest of the martian network cannot talk to the router.
This led to me replugging the ethernet cord back into the wireless router, which at some point in the past had been unplugged. The computers now seem to be happy and can talk to each other.
I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.
The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.
This router was confiscated by the GC guys this morning around ~10am. They barged in and said that someone at the 40m had connected a new router, and we had magically taken down half of the GC network. The cable was plugged in to the wrong port on the back of the router.
Junaid / Christian said that they would "secure" the router, and then reinstall it. Apparently just having a password didn't satisfy them. This was the compromise, versus them just taking the router and never bringing it back.
I retrieved the newly "secured" router from Junaid. It had apparently been hooked up to the GC network via it's LAN port, but it's LAN services had no been shut off. It was therefore offering a competing DHCP server, which will totally hose a network. A definite NONO.
The new SSID is "40mWiFi", it's WPA2, and the password is pasted to the bottom of the unit (the unit is back in it's original spot on the office computer rack.
I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:
Wiring of the power, Ethernet, and indicator lights for the vacuum Acromag chassis is complete. Even though this crate will only use +24V DC, I wired the +/-15V connector and indicator lights as well to conform to the LIGO standard. There was no wiring diagram available, so I had to reverse-engineer the wiring from the partially complete c1susaux crate. Attached is a diagram for future use. The crate is ready to begin software developing on Monday.
Here is my work plan for this week:
1) Help Steve clean small table for experiment
2) Remove aluminum base from TT suspension
3) Mount shaker onto table base
4) Mount horizontal slider onto table base
5) Connect TT suspension, shaker, and horizontal slider
1) Begin building circuit for displacement photosensors
2) Calibrate photosensor using linear regions of power versus distance curves
3) Circuit box for photosensors?
A rough time-table and the various tasks are given below:
Note: 700mW NPRO sitting on AP table (Model No: 126-1064-700, Sl No. 415) = Alberto's laser
Temperature dependence of frequency of Alberto's laser:
a) Shifting Alberto's Laser (AL) to the PSL table and setting up a beat frequency measurement between AL and PSL
b) Determining the frequency vs Temperature curve for the AL
Repositioning the optics on the Y-end table and relocating Alberto's laser ( at this point it will be rechiristened as Y-End-NPRO )
Razib and I were attempting to get the output of a photodiode (PD55A in this case) recorded, so that we could independently measure the slow (~1-10 Hz) fluctuations of the light incident on the camera. This would then allow us to subtract those fluctuations out, letting us get at the camera noise in the case with signal present (as opposed to just a dark noise measurement when we look at the noise with no signal present).
Originally I was thinking of using one empty patch panel BNCs used for PEM channels down by the 1Y7 rack and go through a 110B, although Alberto pointed out he had recently removed some monitoring equipment, which watched the amplitude modulation at various frequencies of the RF distribution (i.e. 33 MHz, etc). This equipment output a DC voltage proportional to the amplitude of the RF signals. The associated channel names were C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_33MHZ_CAL, C1:IOO-RFAMPD_133MHZ, etc. These are slow channels, so I presume they enter in via the slow computers, probably via pentek (I didn't check that, although in hindsight I probably should have taken the time to find exactly where they enter the system). The connections them selves were a set of BNCs on the south side, half way up the 1Y2 rack.
We simply chose one, the 33 MHz channel in this case, and connected. At around this time, the MC did become unlocked, although it looked like it was due to the MC2 watchdog tripping. The initial theory was we had bumped the Mode Cleaner while looking around for some BNC cables, although from what Rana had to do last night, it probably was the connection. We were able to restore the watchdog and confirm that the optic started to settle down again. Unfortunately, I had to leave about 5 minutes later, and didn't do as thorough an investigation as was warranted.
Before I left, I disconnected the PD55, so the 33 MHz channel wasn't physically connected to anything!!! Only one end of the wire was connected to the rack while the other was free...
So it wasn't the PD connection that is responsible for MC tripping at the later time...
Now that the .db files were prepared, I wanted to test for errors. So I did the following:
All the Acromags are seen on the 192.168.114 subnet on c1iscaux3 - however, when I run the modbusIOC process, I see various errors in the logfile , so more debugging is required. Nevertheless, progress.
Update 2245: Turns out the errors were indeed due to a copy/paste error - I had changed the IP addresses for the ADCs from the .115 subnet c1susaux was using, but forgot to do so for the DACs and BIOs. Now, if I turn off the existing c1iscaux so that there aren't any EPICS clashes, the EPICS server initializes correctly. There are still some errors in the log file - these pertain to (i) the mbbo notation, which I have to figure out, and (ii) the fact that this version of EPICS, 7.0.1, does not support channel descriptions longer than 28 characters (we have several that exceed this threshold). I think the latter isn't a serious problem.
Getting closer... Note that I turned off the c1iscaux VME crate to prevent any EPICS server clashes. I will turn it back on tomorrow.
1) Debugging transimpedance calculations in the PDFR
Requires presence of an expert whenever I get inside the lab to take DC measurements or check the illuminating fibers.
2) Creating and incorporating canonical data plots with every measurement of PDFR.
3) Transfer function fitting for transimpedance
4) Improve the Spectrum analyzer scan scripts as mentioned in my elog.
Work Completed :
- Transfer Function
- Quantization Noise Estimation
EPICS and Channel Readout:
Frequency Offset Locking(FOL) Box Design and Plan:
Work Plan for Upcoming Weeks:
See Attachment #1.
The beam spot on ETMY looks weird (looks almost like a TEM10 mode), but the one on ITMY seems fine, see Attachment #2. Wonder what's going on there, maybe just a focusing problem?
We need a vent to fix the suspension, but until then what we can do is to redistribute the POS/PIT/YAW actuations to the three coils.
The variable delay line has been setup for practical use. The hardware and basic software are ready.
The delay time is given by [512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns
Giving 511 (LLLL LLLH HHHH HHHH) to C1:LSC-BO_1_0_SET makes the delayline shortest (+0ns).
Giving 0 (LLLL LLLL LLLL LLLL) to C1:LSC-BO_1_0_SET makes the delayline longest (~32ns).
The SR785 was removed from the rack for our access >> Eric
- Three CONTEC DO-32L-PE cards are found in the Yarm digital cabinet. (I brought a card from WB, but will bring it back).
- The card was installed in the C1LSC chassis.
- The models for c1x04 and c1lsc were modified to include the card. Once they are restarted, the card was recognized without problem.
The frame builder also needed to be restarted (Attachment 1&2). The changes were committed to the repository.
- MEDM screen "CDS_BO_STATUS.adl" has been modified to include the bit monitors for the new DO card. (Attachment 3)
Epics values "C1:LSC-BO_1_0_SET" and "C1:LSC-BO_1_1_SET" are hooked up to the DO block.
- The DO board has DB37(F). I made a I/F cable with a DB37(M) crimp connector, DB25 breakout board, and a ribbon cable.
Pin 1 is connected to pin 14 of the DB25 (GND of the delayline circuit).
Pin 2~10 are connected to pin 1~9 of the DB25 (Switch 1~9 of the delayline circuit)
Pin 18 is connected to X01 (external = spare) (Attachment 4)
- [CONFESSION] A bench +15V power supply was prepared to power the transisters of the DO (Attachment 6). The hot side is connected to X01 (not connected to the DB25),
and the cold side is connected to pin 14 of the DB25. Once we find this is a useful setup we need to make a dedicated interface unit to convert DB37
into DB25 (and provide more connectivities).
- A DB25 M-F cable was installed on the cable tray above the LSC racks.
Delay line unit
- The delay line box was mounted on 34H of the LSC analog rack (Attachment 5).
- The side cross connect power supply was not available (to be described later). Therefore we decided to use the same +15V supply as the one for the DO card.
- Checked the functionarity of the local switches using a function generator @30MHz and the front panel switches. The maximum (~32ns) delay was confirmed.
(Just not enough to have 360 deg shift).
- Now the delay line function was tested with the front panel swicth at "ext". We confirmed that the delay time changes with the number given to C1:LSC-BO_1_0_SET.
What we need further
- Implement delay time slider control (511 = 0ns, 0 = 31.94ns). The delay time is given by
[512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns
- Some independent RF issues I found. (Next entry)
All the details are in E2000436, and documents linked from there, I think an elog would be much too verbose. In summary, a workable setup consisting of
Last night, I locked the PRMI with the carrier resonant, and convinced myself that the DCPD null stream was sensing the MICH degree of freedom (while it was locked on AS55_Q) with good SNR below ~60 Hz. Above ~60 Hz, in this configuration, the ADC noise was dominating, but by next week, I'll have a whitening board installed that will solve this particular issue. With the optical gain of MICH in this configuration, the ADC noise level was equivalent to ~500 nrad/rtHz of phase noise above ~60 Hz (plots later).
Now, I can think about how to commission this setup interferometrically.
[josephb, osamu, kiwamu]
We worked over by the 1Y2 rack today, trying to debug why we didn't get any signal to the c1lsc ADC.
We turned off the power to the rack several times while examining cards, including the whitening filter board, AA board, and the REFL 33 demod board. I will note, I incorrectly turned off power in the 1Y1 rack briefly.
We noticed a small wire on the whitening filter board on the channel 5 path. Rana suggested this was to part of a fix for the channels 4 and 5 having too much cross talk. A trace was cut and this jumper added to fix that particular problem.
We confirmed would could pass signals through each individual channel on the AA and whitening filter boards. When we put them back in, we did noticed a large offset when the inputs were not terminated. After terminating all inputs, values at the ADC were reasonable, measuring on from 0 to about -20 counts. We applied a 1 Hz, 0.1 Vpp signal and confirmed we saw the digital controls respond back with the correct sine wave.
We examined the REFL 33 demod board and confirmed it would work for demodulating 11 MHZ, although without tuning, the I and Q phases will not be exactly 90 degrees apart.
The REFL 33 I and Q outputs have been connected to the whitening board's 1 and 2 inputs, respectively. Once Kiwamu adds approriate LO and PD signals to the REFL 33 demod board he should be able to see the resulting I and Q signals digitally on the PD1 I and Q channels.
In an unrelated fix, we examined the suspensions screens, specifically the Dewhitening lights. Turns out the lights were still looking at SW2 bit 7 instead of SW2 bit 5. The actual front end models were using the correct bit (21 which corresponds to the 9th filter bank), so this was purely a display issue. Tomorrow I'll take a look at the binary outputs and see why the analog filters aren't actually changing.
After hardware errors prevented me from using optimus, I switched my generation of summary pages back to the clusters. A day's worth of data is still too much to process using one computer, but I have successfully made summary pages for a timescales of a couple of hours on this site: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/
Currently, I'm working on learning the current plot-generation code so that it can eventually be modified to include an interactive component (e.g., hovering over a point on a timeseries would display the GPS time). Also, the 40m summary pages have been down for the past 3 weeks but should be up and working soon as the clusters are now alive.
Ok, after a few minutes of talking to Alex, I got the correct "GUI syntax" through my head, and we now have a simple working green end control which in fact puts signals out through the DAC.
Note to self, do not put any additional filters or controls in the IOP module. Basically just change the master block with GDS numbers, DCU_ID numbers, etc. When using a control model, copy the approriate ADC and ADC selector or DAC to the control model. It will magically be connected to the IOP.
A correct example of a simple control model is attached.
Next in line is to get the adapter boxes for SUS into the new 1X5 rack and get started on SUS filter conversion and figuring out which ADC/DAC channels correspond to which inputs.