I've calculated a suitable collimating telescope for the ITMY/SRM oplev laser, based on the specs for the soon-to-arrive 2mW laser (model 1122/P) available here: http://www.jdsu.com/ProductLiterature/hnlh1100_ds_cl_ae.pdf
Based on the fact that the 'beam size' value and 'divergence angle' value quoted don't match up, I am assuming that the beam radius value of 315um is _not_ the waist size value, but rather the beam size at the output coupler. From the divergence angle I calculated a 155um waist, (zR = 12cm). This gives the quoted beam size of about 316um at a distance of 8.5" away from the waist. This makes me think that the output coupler is curved and the waist is at the back of the laser, or at least 8.5" from the output coupler.
The collimating telescope gives a waist of size 1142um (zR=6.47m) at a distance of 1.427m away from the original laser waist, using the following lens combo:
L1 f=-0.15 @ 0.301m
L2 f=0.3 @ 0.409m
This should be fine to get a small enough spot size (1-2mm) on the QPDs.
I just drew a basic picture of how the ITMX oplev path could be reworked to minimise the number of optics in the path. Only possible problem with this might be the turning mirror onto the ITMX getting in the way of the collimating lenses. Should be easy to solve though. Does anyone know if there is a ITMX pick off beam I should be careful to avoid?
First of all I moved the lenses on the ITMY/SRM oplev path to get a smaller spot size on the QPDs. I couldn't get the beam analyzer to work though, so I don't know quite how successful this was. The software brought up the error "unable to connect to framegrabber" or something similar. I don't think the signal from the head was being read by the software. I will try to get the beam analyzer working soon so that we can characterize the other oplev lasers and get decent spot sizes on the QPDs. I searched the elog for posts about the analyzer, and found that it has been used recently, so maybe I'm just doing something wrong in using it.
After this I measured the transfer function for the ITMY oplev yaw. I did a swept sine excitation of the ITMY in yaw with an amplitude of 500, and recorded the OSEM yaw values and the oplev yaw values. This should show a flat response, as both the QPD and the OSEMS should have flat frequency response in the measurement band. This measurement should therefore just yield a calibration from OSEM yaw to oplev yaw. If the OSEM yaw values were already calibrated for radians, we would then immediately have a calibration from oplev yaw values to radians. However, as far as I'm aware, there is not a calibration factor available from OSEM yaw values to radians. Anyway, the TF I measured did not appear to be very flat (see attached plot). Kiwamu suggested I should check the correlation between the OSEM measurements and the oplev QPD measurements - if the correlation is less than 1 the TF is not reliable. Indeed the coherence was poor for this measurement. This was probably because at frequencies above the pendulum frequency, the excitation amplitude of 500 was not enough to cause a measurable change in the optic angle. So, the plot attached is not very useful yet, but I learned something while making it.
In order to estimate the amount of noise that the oplevs are injecting into the GW channel, we first need to calibrate oplev signals in terms of angular change in the optic. I said in my previous post that there wasn't a calibration factor for OSEM values to radians, but I found that Kakeru had estimated this in 2009 - see entry 1413. However, Kakeru found that this was quite a rough estimate, and that it didn't agree with his calibrated oplev values well. He does quote the 2V/mm calibration factor for the OSEM readings though - does anyone know the provenance of this factor? I searched for OSEM calibration and found nothing.
I replaced the lenses that were there with a -150mm lens followed by a +250mm lens. This gave a significantly reduced beam size at the QPDs. With the beam analyzer up and running it should be possible to optimize this later this afternoon. Next I will remove the SRM QPD from the path and make measurements of the beam spot position movement and corresponding OSEM values for different DC mirror offsets. I will then repeat the process for ITMY.
I've got the bench set up for the measurement of the beam spot change with DC SRM alignment offsets. The ITMY oplev is aligned and fine to use, but the SRM one isn't until further notice (probably a couple of hours).
I made the first measurements towards oplev calibration measurements: calibrating the oplevs in SRM YAW. The measurements seemed fine, I had a range of between -1.5 and 1.5 in SRM DC alignment before clipping on mirrors on the oplev bench became a problem. This seemed to be plenty to get a decent fit for the spot position against DC alignment value - see attached plot. The fitted gradient was -420um oplev yaw count. I calculated oplev yaw values as UL+LL-UR-LR. Pitch next.
Same measurements for SRM pitch (as previously done for yaw in entry 5460) are complete. The QPD is back in the path and aligned. I will be doing the same measurements for ITMY now though, so please ask before activating the SRM or ITMY oplev servos, as I may be blocking the beam.
I've now taken data for the pitch and yaw calibrations for the OSEMs of SRM and ITMY. Until such time as I know what the calibrated oplev noise spectra are like, I'm leaving the servo gains at zero.
I estimate the length of the lever arm from SRM to measurement position to be 3.06m, and the length of the lever arm from the ITMY to the measurement position to be 3.13m.
From the fits shown on the attached plots, this gives the following calibration factors for the SRM and ITMY OSEMs pitch and yaw counts (i.e. counts from channels such as SUS-ITMY_ULSEN_SW2 multiplied by a matrix of 1s and -1s) to pitch and yaw angle:
SRM PITCH: 1 OSEMs pitch count = 11.74 microradians
SRM YAW: 1 OSEMs yaw count = 12.73 microradians
ITMY PITCH: 1 OSEMs pitch count = 13.18 microradians
ITMY YAW: 1 OSEMs yaw count = 13.52 microradians
Next step is to do some DC offsets with the oplev paths back in place to get the final calibration between OSEMs counts and oplev counts, thus finally getting a conversion factor from oplev counts to radians.
I noticed while taking these measurements that the DC offsets I put on ITMY caused around 5 times larger change in angle than those on the SRM. The different path length is not enough to account for this, so I propose that the actuation is working differently for the two. I guess this should be taken into account when designing the output matrices (unless the control is passed through a different output matrix than the DC offsets?). I'll quantify the difference shortly, and write a conversion factor between output alignment count (e.g. SUS-ITMY_PIT_COMM) and angle.
The measured calibration factors for the oplevs are as follows:
Kiwamu noticed that the 1/L in the counts per radian should have just been L, which accounts for most of the discrepancy. We checked the input filters on the OSEMs, and they have 10dB of gain at DC. Accounting for this, estimates on the order of 20urad/count, which is much more reasonable!
I found that some of the Optical Lever Servos were ON today and injecting nonsense into the interferometer optics. I have set all of the gains = 0 to save us more headaches.
I had previously set the gains to zero, see the first line of my entry on Monday 5468. I should have the servo and noise characterisation done today for these oplevs today, so we can review it soon.
Here are the open loop transfer functions for ITMY and SRM. The various settings for the OLTFs were as follows:
Oplev filter used for all OLTFs: 300^2:0
Gains for oplev servos (for each OLTF only the 1 servo for the measured TF was on. They are all set back to 0 now):
SRM yaw gain = 1
SRM pitch gain = -1
ITMY yaw gain = -1
ITMY pitch gain = 1
measurement band = 0.2Hz to 200Hz
points = 33
swept sine magnitude envelope: amp = 2 for f > 60Hz, amp = 0.1 for f < 60Hz
Measurement points were from e.g. C1-SUS-ITMY-OLPIT-IN2 to C1-SUS-ITMY-OLPIT-IN1 to give a TF of -(loop gain).
Next step is to divide this through by the sensor reponse (i.e. the calibration factor measured earlier) and the filter response to get just the actuator response.
I divided the open loop transfer functions by the filter response and the sensor responses (previously measured calibration factors) to leave just the actuator responses. I've attached the actuator responses plotted in radians/count and phase over frequency.
Next step: fit the actuator response with poles and zeros.
EDIT: I divided by the wrong filter function earlier - the plots there now are divided by the correct filter function
I used an fminsearch function to fit the SRM and ITMY actuator response magnitudes. The testfunction was just that for a single second order pole, but it gave what I consider to be good fits for the following reasons:
*for 3 of the 4 fits the residuals were less than 0.5% of the summed input data points. The worst one (ITMY pitch) was about 2.7%, which I think is due to the resonance happening to be right in the middle of two data points.
*the tolerance of 1 part in 10^9 was reached quickly from not very finely tuned starting points.
The test function was: G=abs(Gp./(1+1i.*f./fp./Qp-(f./fp).^2)), where G(f) is the actuator response magnitude, Gp is the pole gain, fp is the pole frequency, and Qp is the pole Q factor.
In the end I just fitted the response magnitude. I was initially fitting the complex response function, but ran into problems which I think were cased by overall phase offsets between the data and test function. Can I canvass for opinion if fitting the magnitude is OK, or should I try again fitting the phase too?
Anyway, here are the results of the fits, and I've attached plots of each too (each one in linear and log y axis because each on its own might be misleading for fits):
EDIT - I added more points to the otherwise sparse looking fitted curves
ITMY PITCH actuator response fit
-- Fit completed after 190 iterations--
Started with: Gain = 3e-06,
Q factor = 5,
Pole frequency = 1,
Fit results: Gain = 1.32047e-06,
Q factor = 4.34542,
Pole frequency = 0.676676
Residual (normalised against the sum of input datapoints) = 0.0268321
ITMY YAW actuator response fit
-- Fit completed after 156 iterations--
Fit results: Gain = 1.14456e-06,
Q factor = 8.49875,
Pole frequency = 0.730028
Residual (normalised against the sum of input datapoints) = 0.00468077
SRM PITCH actuator response fit
-- Fit completed after 192 iterations--
Fit results: Gain = 7.94675e-06,
Q factor = 7.16458,
Pole frequency = 0.57313
Residual (normalised against the sum of input datapoints) = 0.00301265
SRM YAW actuator response fit
-- Fit completed after 156 iterations--
Fit results: Gain = 3.34179e-06,
Q factor = 9.57601,
Pole frequency = 0.855322
Residual (normalised against the sum of input datapoints) = 0.000840468
Did you take the 180 deg shift into your account ?
Since your measurement was done when the loop was closed, there must be an additional 180 deg phase shift (in other words, minus sign).
I thought I had, but apparently not, and I'd made another error or two in the complex version of my fitting routine. I've fixed them now, thanks! I'll put up the new fitting results tomorrow morning.
Here are the results of the complex fitting. The residuals are bigger this time, but still probably small enough to be ok(?), with the possible exception of ITMY PITCH (due again I think to the data points straddling the resonance).
ITMY YAW actuator response complex fit
-- Fit completed after 282 iterations--
I thought it might be informative before trying to optimise the filter design to see how the current one performs with different gain settings. I've plotted the power spectra for ITMY yaw with filter gains of 0, 1, 2, 3 and 4.
All of the higher gains seem to perform better than the 0 gain, so can I deduce from this that so far the oplev control loop isn't adding excess noise at these frequencies?
I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.
I have a attached a plot showing the power spectrum and RMS curves for the optimization result for 2 zeros and 2 poles, optimized to give a minimal RMS below 20Hz.
I have also attached a plot showing the loop gain and the filter transfer function.
The noise spectrum shows that the optimised filter gives a better noise performance below 10Hz, but a servo oscillation at the UGF of 10 Hz means it injects a lot of motion around this frequency. Should I consider some more aggressive way to force the script to keep a decent phase margin?
The fminsearch results show that the 'optimized' solution is two resonant peaks:
-- Optimisation completed after 571 iterations--
Pole 1 frequency = 1 Hz
Pole 2 frequency = 2 Hz
Zero 1 frequency = 0.1 Hz
Zero 2 frequency = 5 Hz
Overall gain = 1
Pole 1 frequency = 0.0497181 Hz
Pole 2 frequency = 2.01809 Hz
Zero 1 frequency = 0.0497181 Hz
Zero 2 frequency = 2.01809 Hz
Overall gain = 71970.1
Initial RMS below 10 Hz = 5.90134e-06
Remaining RMS below 10 Hz = 8.42898e-07
(B) The resultant poles and zeros seem canceling each other but the filter still has a structure. Is something wrong ?
Zero 2 frequency = 2.01809 Hz
Ah yes, well noticed. I think I have tracked this down to just a bug in printing of fitting results: It was just printing the pole results for the zeros too. The results for the same fit now read:
Zero 1 frequency = 0.0972455 Hz
Zero 2 frequency = 6.50126 Hz
Overall gain = 71970.1
EDIT: sorry, I forgot that when you write a reply, the author is still by default the person you are replying to unless you change it!
I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.
Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:
1) Limit the gain peaking at the upper UGF to 6 dB.
2) Minimum phase margin of 45 deg.
3) Minimum gain margin of 10 dB.
4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.
5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.
6) Looser noise contraint above 50 Hz for the non TM loops.
I moved two matlab scripts into the folder /cvs/cds/rtcds/caltech/c1/scripts/SUS/Oplev_filter_optimization
These are the function 'filter_optimiser_zeros_and_poles.m', and the example script to run the function 'run_filter_optimiser.m'. Type 'help filter_optimiser_zeros_and_poles.m' to get details about the function.
I haven't implemented the new weights yet. I've pasted them into the the file header to remind me/us of the work to be done on the function.
We have made a new plan for the ITMY and SRM oplev optical path which uses as few optics as possible. This should help to reduce coupling from vibrations of optics in the oplev path back into the GW channel. To get enough room for the turning mirror into the SRM it might be necessary to move the POY optics a bit nearer to the tank.
The 40m Lab reference cavity temperature box S/N BDL3002 was modified as per DCN D010238-00-C.
R1, R2, R5, R6 was 10k now are 25.5k metal film
R11, R14 was 10k now are 24.9k metal film
R10, R15 was 10k now are 127k thick film - no metal film resistors available
R22 was 2.00k now is 2.21k
R27 was 10k now is 33.2k
U5, the LM-336/2.5 was removed
An LT1021-7, 7 V voltage reference was added. Pin 2 to +15V, pin 4 to ground, pin 6 to U6 pin 3.
Added an 8.87k metal film resistor between U6 pin 1 and U4 pin 6.
Added an 8.87k metal film resistor between U6 pin 1 and U4 pin 15.
The 10k resistor between J8 pin 1 and ground was already added in a previous modification.
In addition R3, R4, R7, R8, R12 and R13 were swapped out for metal film resistors of the same value
The jumper connection to the VME setpoint was removed, as per Rana's verbal instructions.
This disables the ability to set the reference cavity vacuum chamber temperature by computer.
To obtain a colored version with good contrast of the grayscale image of scattering of light by dust particles on the surface of test mass, got using GigE camera. The original and colored images are attached here.
Aim: To find telescopic lens solution to image test mass onto the sensor of GigE camera.
I wrote a python code to find an appropriate combination of lenses to focus the optic onto the camera keeping in mind practical constraints like distance of GigE camera from the optic ~ 1m and distance between the lenses need to be in accordance with the Thorlab lens tubes available. We have to image both the enire optic of size 3" and beam spot of 1" using this combination of lens. The image size that efficiently utilizes the entire sensor array is 1/4". Therefore the magnification required for imaging the entire optic is 1/12 and that for the beam spot is 1/4.
I checked the website of Thorlabs to get the available focal lengths of 2" lenses (instead of 1" lenses to collect sufficient power). I have tried several combination of lenses and the ones I found close enough to what is required have been listed below along with thier colorbar plots.
a) 150mm-150mm (Attachment 2 & 3)
With this combination, object distance varies like 50cm for 1" beam spot to 105cm for 3" spot. Therefore, it posses a difficulty that there is a difference of ~48cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.
b) 125mm-150mm (Attachment 4 & 5)
With this combination, object distance varies like 45cm for 1" beam spot to 95cm for 3" spot. There is a difference of ~43cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.
c) 125mm-125mm (Attachment 6 & 7)
The object distance varies like 45cm for 1" beam spot to 90cm for 3" spot. There is a difference of ~39cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.
Sensitivity check was also done for these combination of lenses. An error of 1cm in object distance and 5mm in the distance between the lenses gives an error in magnification <2%.
The schematic of the telescopic lens system has been given in Attachment 8.
Set up gwsumm on optimus and generated summary pages from both L1 and C1 data. Still a few manual steps need to be taken during generation, not fully automated due to some network/username issues. nds2 now working from optimus after restarting nds2 server.
Found 1 out of 2 bluebird microphones in the 40m.
Found 60 EM172 microphones. Previous elog with details: 7777.
There has been an ongoing memory error in optimus with the following messages:
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705127] [Hardware Error]: Corrected error, no action required.
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705174] [Hardware Error]: CPU:24 (10:4:2) MC4_STATUS[Over|CE|MiscV|-|AddrV|CECC]: 0xdc04410032080a13
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705237] [Hardware Error]: MC4_ADDR: 0x0000001ad2bd06d0
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705264] [Hardware Error]: MC4 Error (node 6): DRAM ECC error detected on the NB.
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705323] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)
Optimus is a Sun Fire X4600 M2 Split-Plane server. Based on this message, the issue seems to be in memory controller (MC) 6, chip set row (csrow) 7, channel 0. I got this same result again after installing edac-utils and running edac-util -v, which gave me:
mc6: csrow7: mc#6csrow#7channel#0: 287 Corrected Errors
and said that all other DIMMs were working fine with 0 errors. Each MC has 4 csrows numbered 4-7. I shut off optimus and checked inside and found that it consists of 8 CPU slots lined up horizontally, each with 4 DIMMs stacked vertically and 4 empty DIMM slots beneath. I'm thinking that each of the 8 CPU slots has its own memory controller (0-7) and that the csrow corresponds to the position in the vertical stack, with csrow 7 being the topmost DIMM in the stack. This would mean that MC 6, csrow 7 would be the 7th memory controller, topmost DIMM. The channel would then correspond to which one of the DIMMs in the pair is faulty although if the DIMM was replaced, both channels 0 and 1 would be switched out. Here are some sources that I used:
I'll find the exact part needed to replace soon.
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.
I've added a new tab for VMon under the SUS parent tab. I'm still working out the scale and units, but let me know if you think this is a useful addition. Here's a link to my summary page that has this tab: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1151193617-1151193917/sus/vmon/
I'll have another tab with VMon BLRMS up soon.
Also, the main summary pages should be back online soon after Max fixed a bug. I'll try to add the SUS/VMon tab to the main pages as well.
The main C1 summary pages are back online now thanks to Max and Duncan, with a gap in pages from June 8th to July 4th. Also, I've added my new VMon and Sensors tabs to the SUS parent tab on the main pages. These new tabs are now up and running on the July 7th summary page.
Here's a link to the main nodus pages with the new tabs: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160707/sus/vmon/
And another to my ldas page with the tabs implemented: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1150848017-1150848317/sus/vmon/
Let me know if you have any suggestions or see anything wrong with these additions, I'm still working on getting the scales to be right for all graphs.
Optimus' memory errors are back so I found the exact DIMM model needed to replace: http://www.ebay.com/itm/Lot-of-10-Samsung-4GB-2Rx4-PC2-5300P-555-12-L0-M393T5160QZA-CE6-ECC-Memory-/201604698112?hash=item2ef0939000:g:EgEAAOSwqBJXWFZh I'm not sure what website would be the best for buying new DIMMs but this is the part we need: Samsung 4GB 2Rx4 PC2-5300P-555-12-L0 M393T5160QZA-CE6.
A new MEDM tab has been added to the summary pages (https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160708/medm/), although some of the screens are not updated when /cvs/cds/projects/statScreen/cronjob.sh is run. In /cvs/cds/projects/statScreen/log.txt, the following error is given for those files: import: unable to read X window image `0x20011f': Resource temporarily unavailable @ error/xwindow.c/XImportImage/5027. If anyone has seen this error before or knows how to fix it, please let me know.
In the meantime, I'll be working on creating an archive of MEDM screens for every hour to be displayed on the summary pages.
Thanks! Yes, only the screens that are not updated when the script is executed show this error. I'll try to keep debugging over the weekend.
Some of the screens are up-to-date, and some are not. Are the errors associated with the screens that failed to get updated?
The MEDM screen capture tab is now working and up on the summary pages: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160725/medm/
Please let me know if you have any suggestions or notice any issues.
I recreated Den's microphone amplifier circuit on a solderless breadboard to test it and make sure it does what it's supposed to. So far it seems like everything is working- I'll do some testing tomorrow to see what the amplified output is like for some test noises. Here's the circuit diagram that Den made (his elog as well https://nodus.ligo.caltech.edu:8081/40m/6651):
I'm not sure why he set up the circuit the way he did- he has pin 7 grounded and pin 4 going to +12V while in the datasheet for the opamp (http://cds.linear.com/docs/en/datasheet/1677fa.pdf), pin 7 goes to positive voltage and pin 4 goes to negative voltage. There's some other strange things about the circuit that I don't really understand, such as the motivation for using no negative voltage source, but for now I'm going to stick with Den's design and then make some modifications after I have things working and a better understanding of the problem.
Here's my current plan:
-Make sure Den's amplifier works, test it out and make changes if necessary
-Make multiple amplifier circuits on soldering breadboard
-Either make a new amplifier box or reuse Den's old box depending on how many changes I make to the original circuit
-Solder EM172s to BNC connectors, set them up around the floor suspended
-Get the amplifier box hooked up, set up some data channels for the acoustic noise
-Add new acoustic noise tab to the summary pages
Den also mentioned that he wanted me to measure the coupling of acoustic noise to DARM.
I set up a test inverting amplifier circuit using the LT1677 opamp:
The input signal was a sine wave from the function generator with peak to peak amplitude of 20 mV and a frequency of 500 Hz and I received an output with an amplitude of about 670 mV and the same 500 Hz frequency, agreeing with the expected gain of -332k/10k = -33.2:
So now I know that the LT1677 works as expected with a negative supply voltage. My issue with Den's original circuit is that I was getting some clipping on the input to pin 2, which didn't seem to be due to any of the capacitors- I switched them all out. I set up a modified version of Den's circuit using a negative voltage input to see if I could fix this clipping issue:
I might reduce the input voltages to +5V and -5V- I couldn't get my inverting amp circuit to work with +12V and -12V. I'll start testing this new circuit next week and start setting up some amplifier boxes.
I could not get Den's circuit to work for some reason with microphone input, so I decided to try to use another circuit I found online. I made some modifications to this circuit and made a schematic:
Using this circuit, I have been able to amplify microphone input and adjust my passband. Currently, this circuit has a high-pass at about 7 Hz and a low-pass at about 23 kHz. I tested the microphone using Audacity, an audio testing program. I produced various sine waves at different frequencies using this program and confirmed that my passband was working as intended. I also used a function generator to ensure that the gain fell off at the cutoff frequencies. Finally, I measured the frequency response of my amplifier circuit:
A text file with the parameters of my frequency response and the raw data is attached as well.
These results are encouraging but I wanted to get some feedback on this new circuit before continuing. This circuit seems to do everything that Den's circuit did but in this case I have a better understanding of the functions of the circuit elements and it is slightly simpler.
# SR785 Measurement - Timestamp: Aug 03 2016 - 18:04:48
#---------- Measurement Setup ------------
# Start frequency (Hz) = 1.000000
# Stop frequency (Hz) = 102400.000000
# Number of frequency points = 800
# Excitation amplitude (mV) = 50.000000
# Settling cycles = 1
# Integration cycles = 5
#---------- Measurement Parameters ----------
# Measurement Group: "Swept Sine" "Swept Sine"
The Guralp cable has been pulled and put in the corner to the left of the water cooler:
Ben came by today before the cable had been pulled but he said he'll be back tomorrow.
I took the spectrum of an EM172 connected to my amplifier inside and outside a large box filled with foam layers:
I also made a diagram with my plan for the microphone amplifier boxes. This is a bottom view:
The dimensions I got from this box: http://www.digikey.com/product-detail/en/bud-industries/CU-4472/377-1476-ND/696705
This seemed like the size I was looking for and it has a mounting flange that could make suspending it easier. Let me know if you have any suggestions.
I'll be doing a Huddle test next week to get a better idea of the noise floor and well as starting construction of the circuits to go inside the boxes and the boxes themselves.
The Guralp cable has been reconnected and powered after having the connector changed out.
I set up 3 of my circuits in the interferometer near MC2 to do a huddle test. I have the signals from my microphones going into C1:PEM-MIC_1_IN1, C1:PEM-MIC_2_IN1, and C1:PEM-MIC_3_IN1. These are channels C17-C19. Here are some pictures of my setup:
I'll likely be collecting data from this for a couple of hours. Please don't touch it for now- it should be gone soon. There are some wires running along the floor near MC2 as well.
The summary pages have been updated with the new naming seismometer channel naming conventions. Here's a link to them working on my own page: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1154908817-1154909717/pem/seismic/
Let me know if the actual pages aren't working when they come back online or if there's something that needs to be changed.
The results of my first huddle test were not so good- one of the signals did not match the other two very well- so I changed the setup so that the mics would be better oriented to receive the same signal. Pictures of the new setup are attached.
I also noticed some problems with one of my microphones so I soldered a new mic to bnc and switched it out. Just judging from Dataviewer, the signals seem to be more similar now. I'll be taking data for another few hours to confirm.
I used the Wiener filtering method described by Ignacio and Jessica (https://dcc.ligo.org/DocDB/0119/T1500195/002/SURF_Final.pdf and https://dcc.ligo.org/public/0119/T1500194/001/Final_Report.pdf) and got the following results:
The channel readout has a gain of 0.0005 and the ADC is 16-bit and operates are 20V. The channel also reads the data out in Pa. I therefore had to multiply the timeseries by 1/0.0005=2000 to get it in units of counts and then by (20 Volts)/(2^16 counts) to get back to the original signal in volts. The PSDs were generated after doing this calibration. I also squared, integrated, and square rooted the PSDs to get an RMS voltage for each microphone as a sanity check:
Mic 1: 0.00036 V
Mic 2: 0.00023 V
Mic 3: 0.00028 V
These values seem reasonable given that the timeseries look like this: