Force to Angle. It just means the filters that are in the POS OUTPUT matrix. I think in the past sometimes they are called F2P or F2A.
These filters account for the frequency dependent coupling of the DOFs around the suspension resonance. Take a look at what Bhavini is doing for the plots.
Today image capture did not work again, though it had worked 3 days before. I also found that red indicator light on the front pannel of SENSORAY was not turned on, which had been turned on 3 days before (you can find SENSORAY on the floor near Pianosa). Possible reason that it did not work again was I restarted Pianosa last night. Anyway, it works now. Here I report what I did to make it work.
I ran thes commands in shell, following the instruction of the manual of SENSORAY 2253 (Page 5; link or you can find the manual in /users/sensoray; I put it there).
> cd /users/sensoray/sdk_2253_1.2.2_linux
> make all
> sudo make install
> modprobe s2253
Then the red light got turned on, and image capture worked.
If you recieve an error like "No such file or directory: /dev/video0" at the beginning of the error message when you run image capture scripts from the medm screen, or if you notice that the red indicator light of SENSORAY is not on, this procedure could help you.
Do we need "make" everytime? Do you mean just running "modprobe" didn't work?
I don't know if just running "modprobe" will work or not, because I didn't try it... When the same problem happens again, we can try just running "modprobe" first.
I can't find the DELL laptop anywhere in the lab. Does anyone know where it is?
Also one of the two netbooks is missing.
One dell is in the clean room for the suspension work.
While trying to implement the regular yellow shell script button in MEDM for my new OAF screen, I noticed that the update snapshot stuff in all of the buttons that I checked (including IFO Align and LSC Overview) are pointing to folders in the old /cvs/cds/caltech/ area. Also, I think some of the folders that it's looking for don't exist anymore, even in the old system. So. Has anyone thought about where the snapshots should live in the new world order? Previously they were in ...../medm/c1/subsystem/ . Maybe we should make a snapshots folder in each subsystem's medm folder, at the same level as the 'master' folder for the custom screens? This is my current proposal.
Unless someone objects / has a better plan / knows why they're still pointing to the old place, I'll do this in the morning, and work on changing all the buttons to point to the new place.
The following directory exists. We can apply this convention to all of the models.
Alex checked out the old rts (which he is no longer sure how to compile) from CVS to megatron, to the directory:
In /home/controls/cds/rts/src/include you can find the various h files used. Similarly, /fe has the c files.
In the h files, you can work out the memory offset by noting the primary offset in iscNetDsc40m.h
A line like suscomms.pCoilDriver.extData determines an offset to look for.
0x108000 (from suscomms )
Then pCoilDriver.extData[#] determines a further offset.
sizeof(extData) = 8240 (for the 40m - you need to watch the ifdefs, we were looking at the wrong structure for awhile, which was much smaller).
DSC_CD_PPY is the structure you need to look in to find the final offset to add to get any particular channel you want to look at.
The number for ETMX is 8, ETMY 9 (this is in extData), so the extData offset from 0x108000 for ETMY should be 9 * 82400. These numbers (i.e. 8 =ETMX, 9=ETMY) can be found in losLinux.c in /home/controls/cds/rts/src/fe/40m/. There's a bunch of #ifdef and #endif which define ETMX, ETMY, RMBS, ITM, etc. You're looking for the offset in those.
So for ETMY LSC channel (which is a double) you add 0x108000 (a hex number) + (9 * 82400 + 24) (not in hex, need to convert) to get the final value of 0x11a160 (in hex).
A useful program to interact with the RFM network can be found on fb40m. If you log in and go to:
you can then run rfm2g_util, give it a 3, then type help.
You can use this to read data. Just type help read. We had played around with some offsets and various channels until we were sure we had the offsets right. For example, we fixed an offset into the ETMY LSC input, and saw the corresponding memory location change to that value. This utility may also be useful for when we do the RFM test to check the integrity of the ring, as there are some diagnostic options available inside it.
I have a simulated version of the differences that we expect to see between the 2 different sides of the CARM resonance. The point is that we can try to compare these results with Q's measured results (elog 10594) to see if we know if we are on the spring or antispring side.
I calculated the same transfer functions vs CARM offset again, although tonight I do it in steps of 20pm because I was getting bored of waiting forever. Anyhow, this is important because my previous post (elog 10591) didn't have spring side calculations all the way down to 1pm.
This is similarly true for that elog 10591, but here are some notes on how I am currently getting the W/N units out of Optickle. First of all, I am still using old Optickle1. I don't know if there are significant units ramifications for that, but just in case I'll write it down. Nic tells me that to get [W/N] out of Optickle1, I need to multiply sigAC (units of [W/m]) by my simple pendulum (units of [m/N]). Both of these "meters" in the last sentence are "mevans meters", which are the meters you would get per actuation if radiation pressure didn't exist. So, I guess they're supposed to cancel out? I need to camp out in Nic's office until I figure this out and get it untangled in my head.
Plots of transfer functions for both sides of CARM resonance (same as prev. elog), as well as the ratio between the spring and antispring transfer functions at each CARM offset:
The take-away message from the 3rd column is that other than a sign flip, we don't expect to see very much difference between the 2 sides of the CARM resonance, particularly above a few hundred Hz. (Note that we do not see the sign flip in Q's measurements because he is looking at CARM_IN1, which is after the input matrix, and the input matrix elements have opposite signs between the signs of the CARM offsets. So, the sign flip between spring and antispring around the UGF is implied in the measurements, just not explicit).
Also, something that Rana pointed out to me, and I still don't know why it's true: The antispring transfer functions (at least for the transmission) don't have all the phase features that we expect to see based on their magnitudes. If you look at the TRX antispring plot, blue trace (which is about 500pm from resonance), you'll see that the magnitude starts flat at DC, has some slope in an intermediate region, and then at high frequencies has 1/f^2. However, the phase seems to not know about this intermediate region, and magically waits until the 1kHz resonance to flip the full 180 degrees.
I made some measurements to try and see if any difference could be seen with different CARM offset signs.
Specifically, at various offsets, I used a spare DAC channel to drive IN1 of the CM board, as an "AO Exciter." I used CM_SLOW to monitor the signal that was actually on the board. I used the CARM_IN1 error signal to see how the optical plant responded to the AO excitation. Rather than a swept sine, I used a noise injection kind of TF measurement.
Here are plots of CARM_IN1 / CM_SLOW at different CARM FM offsets; I chose to plot this in an attempt to divide out some of the common things like AA and delays and make the detuned CARM pole more evident). The offsets chosen correspond roughly to powers of 2, 2.5, and 3. I tried to go higher than that, but didn't remain locked for long enough to measure the TF.
By eye, I don't see much of a difference. We can zpk fit the data, and see what happens.
I went back into the DQ channels to look at the TF from AO injection to REFLDC (which is easy to do with this kind of noise injection TF).
I fear that REFL does not seem to have as much phase under the resonance as we have modeled, lacking about 10-20 degrees. This could result from the zero in the REFL DC response that we've modeled at ~200ish Hz is actually higher. I'll look into what affects the frequency of that feature.
It is, of course, possible, that this measurement doesn't properly cancel out the various digital effects, but the REFLDC phase curves do seem to settle to (+/-) 90 after the pole as expected.
DTT XML file is attached.
Some measurements. Unclear meaning.
We tried both positive and negative numbers in the CARM offset, and then looked at transfer functions at various arm powers. The hope is to be able to compare these with some simulation to figure out which side of the CARM resonance we are on.
The biggest empirical take-away is that we repeatedly (3 times in a row) lost lock when holding at arm powers of about 5 with negative CARM offsets. However, we were repeatedly (2+ times tonight) able to sit and hold at arm powers of 10+ with positive CARM offsets.
I am not sure that we get enough information out of these plots to tell us which side of the CARM resonance we are really on. Q is working on taking some open loop CARM measurements (actuating and measuring at SUS-MC2_LSC) to see if we can compare those more directly to Rana's plots.
Positive number in the digital CARM offset:
Negative numbers in digital CARM offset:
In order to distinguish between the spring and antispring sides of the CARM resonance, we need to have transfer function measurements down to at least 100 Hz (although lower is better).
We tried to get some transfer functions the same way Q did, but noticed that (a) we couldn't get any low frequency coherence, and (b) that when we increased the amplitude of the white (well, lowpass at 5kHz) noise, the coherence between the AO injection and REFL DC went down. Not clear why this is.
Anyhow, we tried taking good ol' fashioned swept sine transfer functions, although eventually the lightbulb came on that the AO path has a highpass in it. Duh, Jenne. So, we started trying to actuate on MC2 position rather than the AO path laser frequency. We didn't get too far though before El Salvadore decided to have a few 7.4 earthquakes. We're bored of aftershocks knocking us out of lock, so we're going to come back to this tomorrow.
Since no one was here, I started the Ubuntu 10 - 12 upgrade on Rossa. It didn't run at first because it wanted to remove 'update-manager-kde' even though it was on the blacklist. I removed it from the command line and now its running. Allegra, OTOH, refuses to upgrade. Someone please ask Diego to wipe it and then install Ubuntu 12 LTS on there in the morning...its a good way to learn the Martian CDS setup.
I have plotted measured data from last night (elog 10607) with a version of the result from Rana's simulink CARM loop model (elog 10593).
The measured data that was taken last night (open circles in plots) is with an injection into MC2 position, and I'm reading out TRX. This is for the negative side of the digital CARM offset, which is the one that we can only get to arm powers of 5ish.
The modeled data (solid lines in plots) is derived from what Rana has been plotting the last few days, but it's not quite identical. I added another excitation point to the simulink model at the same place as the "CARM OUT" measurement point. This is to match the fact that the measured transfer functions were taken by driving MC2. I then asked matlab to give me the transfer function between this new excitation point (CARM CTRL point) and the IN1 point of the loop, which should be equivalent to our TRX_OUT. So, I believe that what I'm plotting is equivalent to TRX/MC2. The difference between the 2 plots is just that one uses the modeled spring-side optical response, and the other uses the modeled antispring-side response.
I have zoomed the X-axis of these plots to be between 30 Hz - 3 kHz, which is the range that we had coherence of better than 0.8ish last night in the measurements. The modeled data is all given the same scale factor (even between plots), and is set so that the lowest arm power traces (pink) line up around 150 Hz.
I conclude from these plots that we still don't know what side of the CARM resonance we are on.
I have not plotted the measurements from the positive side of the digital CARM offset, because those transfer functions were to sqrtInvTRX, not plain TRX, whereas the model only is for plain TRX. There should only be an overall gain difference between them though, no phase difference. If you look at last night's data, you'll see that the positive side of the CARM offset measured phase has similar characteristics to the negative offset, i.e. the phase is not flat, but it is roughly flat in both modeled cases, so even with that data, I still say that we don't know what side of the CARM resonance we are on.
I made some rough measurements, using the setup I had used for CCD calibration, to get an idea of how good of a Lambertian scatterer the white paper is. Following are the values I got:
Note: All the measurements are just rough ones and are prone to larger errors than estimated.
I also measured the transmittance of the white paper sample being used (it consists of 2 white papers wrapped together). It was around 0.002
I finally managed to install a differential-receiving whitening board in 1Y2 - 4 channels are available at the moment. As I claimed, one stage of 15:150 Hz z:p whitening does improve the ALS noise a little, see Attachment #1. While the RMS (from 1kHz-0.5 Hz) does go down by ~10 Hz, this isn't really going to make any dramatic improvement to the 40m lock acquisiton. Now we're really sitting on the unsuppressed EX laser noise above ~30 Hz. This measurement was taken with the arm cavities locked with POX/POY, and end lasers locked to the arm cavities with uPDH boxes as usual. This was just a test to confirm my suspicion, the whitening board is to be used for the air BHD channels, but when we get a few more stuffed, we can install it for the ALS channels too.
No, there should be no unscheduled visits from any inspector, marshal, tech, or vendor. They all have to be escorted or they don't get in. If they have a problem with that, please give them my cell #.
For the ALS, in addition to the beat note spectrum, I think we need to know the loop gain use to feedback to the ETM to determine the true cavity length fluctuation. w/o ALS, the noise would be only due to the seismic noise, OSEM damping noise, and the IR-PDH residual. Those are all suppressed by the ALS loop, but then the ALS loop puts its sensing noise onto the cavity. So, if I'm thinking about this right, the ALS beat noise > 200 Hz doesn't matter so much to the CARM RMS. So the whitening seems to be doing good in the right spot, but we would like to have another boost in the green PDH to up the gain below ~300 Hz?
With the chosen transimpedance of 300 ohms, in order to be able to see the shot noise of 10 mW of light in the digitized data streams, we'd need all 3 stages of whitening. If we want to be shot noise limited with 1 mW of LO light, we'd need to increase said transimpedance I think.
The measurements were taken with
Of course, it's unlikely we're going to be shot noise limited for any configuration in the short run. But this was also a test of
All 3 tests passed.
For whitening electronics noise for WFS1, I get (attachment). This doesn't seem right, right?
We use D990694 in various places. Today, Rana alerted me to an important consideration to be kept in mind when we use this board, which I found quite interesting. I still don't understand the problem at the BJT level, but I think one can appreciate the problem without going to the transistor design of the LT1125. I'm attaching an annotated schematic of the whitening section in question. If the following assumptions are valid, then I think my picture is valid.
Then, as one can see in the attached schematic, when we set the gain of any input to <24dB, we must ensure that the input voltage is less than approximately 2V. Otherwise, by asking too much of the first stage op-amp in the quad IC LT1125, we may be messign around with all the 4 op amps in the quad! Even the 0dB setting is not immune to this problem, as it uses one of the 4 op amps.
Now that I think about this a bit more - this problem shouldn't be significant for the usual LSC degrees of freedom when in lock, as the huge DC gain of the loop should squish large DC values of the error signals, and so there shouldn't be any danger of overloading the LT1125. But I don't know if we are being hurt by this effect when flashing through resonances, when the PDH horn-to-horn voltage can be quite high (which is in principle a good thing?). I don't know if there is any "hysterisis" effect where the overloaded quad IC has some relaxation time before it returns to normal operation, and if we are being limited in our ability to catch lock because if this effect.
The concerns remain valid for th ALS demodulated error signals though, for which the signals will remain large throughout.
this is the note from Hartmut Grote on this topic from 2004
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?).
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.