I will attach a document which describes how the noise affect the wiener filter and the noise cancellation ratio.
And I re-estimate the SN ratio in the microphone (but still rough):
The yellow line is modeled signal level, and cyan line is modeled noise level.
Then, the estimated filtered residual noise is:
The noise is already subtracted enough below 80 Hz even though there is still coherence.
Above 300 Hz, the residual error is limited by other noise than acoustic noise since there is no coherence.
I am not sure about the region between 100-300 Hz, but I guess that we cannot subtract the acoustic noise because primary noise (see the document), such as a peak at 180 Hz, is so high.
In order to perform acoustic noise cancellation with MCL signal, I am trying to find sweet spots for microphones.
I set microphones at various places around MC chambers, and see how coherent microphones and MC signals are.
I had checked the half part of MC.
The acoustic noise around the MC2 chamber is most critical so far. I could subtract the signal and the sensitivity got 2 times better.
I will see the acoustic coupling from the other side of MC.
Last Thursday, I put the speaker and my laptop in the PSL table, and make triangular wave sound with the basic frequency of 40Hz, and Gaussian distributed sound.
(I create the sounds from my laptop using the software 'NHC Tone Generator' because I could not find the connector from BNC to speaker plug.)
And I measured the acoustic coupling in MCF signal. The all the 6 microphones were set in PSL table around PMC and PSL output optics.
The performance of the offline noise cancellation with wiener filter is below.
(The target signal is MCF and the witness signals are 6 microphones.)
I can see some effects on MCF due to the sound on PSL table. Though I can subtract some acoustic signal and there are no coherence between MCF signal and mic signals, still some acoustic noise remains.
This is maybe because of some non-linearity effects or maybe because we have other effective places for acoustic coupling measurement. More investigations are needed.
Also, I compared the wiener filter and the transfer function from microphones signal to MCF signal. They should be the same ideally.
(Left: Wiener filter, Right: Transfer function estimated by the spectrum. They are measured when the Gaussian sound is on.)
These are different especially lower frequencies than 50 Hz. The wiener filter is bigger at lower frequencies. I guess this adds extra noise on the MCF signal. (see the 1st figure.)
The wiener filter can be improved by filterings. But if so, I want to know how can we determine the filters. It is interesting if we have some algorithms to determine the filters and taps and so on.
The more investigations are also needed.
I have been searching for the way we can subtract signal better since I could see the acoustic coupling signal remains in the target signal even though there are no coherence between them.
I changed the training time which is used to decide wiener filter.
I have total 10 minutes data, and the wiener filter was decided using the whole data before.
(Right: the performance with the data when the triangular sound was created. Left: the performance with the data when the gaussian sound was created.)
I found that the acoustic signal can be fully subtracted above 40 Hz when the training time is short. This means the transfer functions between the acoustic signals and MCF signal change.
However, if the wiener filter is decided with short-time training, the performances at lower frequencies get worse. This is because wiener filter do not have enough low-frequency information.
So, I would like to find the way to combine the short-time training merit and long-time training merit. It should be useful to subtract the broad-band coupling noise.
In order to see the acoustic coupling on arm signals, I set 6 microphones and the speaker on the AP table. The microphones are not seismically isolated for now.
I have a signal generator under the AP table.
When I played the 43 Hz triangular wave sound, I could see some coherence between POY error signal and microphones even though there is no peak in POY.
Don't try to re-invent the mic mount: just copy the LIGO mic mount for the first version.
Yesterday, I made new mounts for microphones.
I glued a microphone on a pedestal. The cables are attached loosely so that its tension does not make any noise.
At the bottom of the mount, I attached the surgical tube forming a ring by double-side tape so that it damps the seismic vibration.
I made 6 mounts and these are all on the AS table now.
I took some data of XARM signal controlled by AS.
My plan is to find/set an upper limit on acoustic coupling noise in AS signal.
The acoustic noise can be estimated by the Wiener filter, but it is not accurate because it may see residual correlation between AS and microphone signals that should be 0 when the data is long enough.
I will find/set an upper limit by the analysis based on Neuman-Pearson criterion, that is analog of a stochastic GW background search.
If I can find the acoustic coupling noise should be below the shot noise, I am happy. If not, some improvements may be needed someday.
I have done a quicky offline Wiener filter to check how much PRM yaw motion we can subtract using a seismometer in the corner station. This work may be redundant since Koji got the POP beam shadow sensor feedback loop working on Friday night.
Anyhow, for now, I used the GUR2 channels, since GUR2 was underneath the ITMX chamber (at the north edge of the POX table). Note that Zach is currently borrowing this seismometer for the week.
I used GUR2_X, GUR2_Y and GUR2_Z to subtract from the PRM_SUSYAW_IN1 channel (the filename of the figure says "GUR1", but that's not true - GUR1 is at the Yend). All 4 of these channels had been saved at 2kHz, but I downsampled to 256 (I probably should downsample to something lower, like 64, but haven't yet). There is no pre-filtering or pre-weighting of the data, and no lowpass filters applied at the end, so I haven't done anything to remove the injected noise at higher freqs, which we obviously need to do if we are going to implement this online.
If I compare this to Koji's work (elog 8562), at 3.2Hz, he gets a reduction of 2.5x, while this gets 10x. At all other frequencies, Koji's work beats this, and Koji's method gets reduction from ~0.03Hz - 10Hz, while this is only getting reduction between 0.4Hz and 5Hz. Also, this does not include actuator noise, so the actual online subtraction may not be quite as perfect as this figure.
In order to do online static IIR Wiener filtering one needs to do the following,
1) Get data for FIR Wiener filter witnesses and target.
2) Measure the transfer function (needs to be highly coherent, ~ 0.95 for all points) from the actuactor to the control signal of interest (ie. from MC2_OUT to MC_L).
3) Invert the actuator transfer function.
4) Use Vectfit or (LISO) to find a ZPK model for the actuator transfer and inverse transfer functions.
5) Prefilter your witness data with the actuator transfer function, to take into account the actuator to control transfer function when designing the offline Wiener FIR filter.
6) Calculate the frequency response for each witness from the FIR coefficients.
7) Vectfit the frequency reponses to a ZPK model, this is the FIR to IIR Wiener conversion step.
8) Now, either, divide the IIR transfer function by the actuator transfer function or more preferably, multiply by the inverse transfer function.
9) Use Quack to make SOS model of the IIR Wiener filter and inverse transfer function product that goes into foton for online implementation.
10) Load it into the system.
The block diagram below summarizes the steps above.
I took some training data during Sunday night/Monday morning while the MCL MISO FF was turned on. We wanted to see how much residual noise was left in the WFS1/WFS2 YAW and PITCH signals.
The offline subtractions that can be achieved are:
I need to download data for these signals while the MCL FF is off in order to measure how much subtraction was achived indirectly with the MCL FF. In a previous elog:11472, I showed some offline subtractions for the WFS1 YAW and PITCH before any online FF was implemented either by me or Jessica. From the plots of that eLOG, one can clearly see that the YAW1 signal is clearly unchanged in the sense of how much seismic noise was mitigated indirectly torugh MCL.
Koji has implemented the FF paths (thank you based Koji) necessary for these subtractions to be implemented. The thing to figure out now is where we want to actually actuate and to measure the corresponding transfer functions. I will try to have either Koji or Eric help me measure some of these transfer functions.
Finally, I looked at the ARMS and see what residual seismic noise can be subtracted
I'm not too concerned about noise in the arms as if the WFS subtractions turn out to be promising then I expect for some of the arms seismic noise to go down a bit further. We also don't need to measure an actuator transfer function for arm subtractions, give that its essentially flat at low frequencies, (less than 50 Hz).
Here's something to ponder.
Our online MCL feedforward uses perpendicular vertex T240 seismometer signals as input. When designing a feedforward filter, whether FIR Wiener or otherwise, we posit that the PSD of the best linear subtraction one can theoretically achieve is given by the coherence, via Psub = P(1-C).
If we have more than one witness input, but they are completely uncorrelated, then this extends to Psub = P(1-C1)(1-C2). However, in reality, there are correlations between the witnesses, which would make this an overestimate of how much noise power can be subtracted.
Now, I present the actual MCL situation. [According to Ignacio's ELOG (11584), the online performance is not far from this offline prediction]
Somehow, we are able to subtract much more noise at ~1Hz than the coherence would lead you to believe. One suspicion of mine is that the noise at 1Hz is quite nonstationary. Using median [C/P]SDs should help with this in principle, but the above was all done with medians, and using the mean is not much different.
Thinking back to one of the metrics that Eve and Koji were talking about this summer, (std(S)/mean(S), where S is the spectrogram of the signal) gives an answer of ~2.3 at that peak at 1.4Hz, which is definitely in the nonstationary regieme, but I don't have much intution into just how severe that value is.
So, what's the point of all this? We generally use coherence as a heuristic to judge whether we should bother attempting any noise subtraction in the first place, so I'm troubled by a circumstance in which there is much more subtraction to be had than coherence leads us to believe. I would like to come up with a way of predicting MISO subtraction results of nonstationary couplings more reliably.
The puzzle continues...
I found some reference for computing "multicoherence," which should properly estimate the potential MISO subtraction potential in situations where the witness channels themselves have nontrivial coherence. Specifically, I followed the derivations in LIGO-P990002. The underlying math is related to principal component analysis (PCA) or gram-schmidt orthogonalization.
This produced the following results, wherein the Wiener subtraction is still below what the coherences predict.
I've attached the data and code that produced this plot.
The anticlimatic resolution to my subtraction confusion: Spectral leakage around 1Hz. Increasing the FFT length to 256 sec now shows that the FIR WF pretty much achieves the ideal subtraction.
If nothing else, it's good to have worked out how MISO coherence works.
Just not just pedagogical ! Freq domain MISO coherence based subtraction estimation is much faster than calculating MISO WF. And since each bin is independent of each other, this gives us an estimate of how low the noise can go, whereas the Wiener filter is limited by Kramers-Kronig. We should be able to use this on the L1 DARM channel to do the noise hunting as well as estimating the subtraction efficacy of the pseudo channels that you and Rory come up with.
If you can code up a noise hunter example using DARM + a bunch of aux channels, we could implement it in the summary pages code.
I've been banging my head against bilinear noise subtraction, and figured I needed to test things on some real hardware to see if what I'm doing makes sense.
I ran the ASS dither alignment on the Y arm, which ensures that the beam spots are centered on both mirrors.
I then drove ITMY in yaw with some noise bandpassed from 30-40 Hz. It showed the expected bilinear upconversion that you expect from angular noise on a centered beam, which you can see from 60-80 Hz below
I looked at the length signal, as the noise subtraction target, and the ITMY oplev yaw signal plus the transmon QPD yaw signal as witnesses.
There is some linear coupling to length, which means the the centering isn't perfect, and the drive is maybe large enough to displace it off center. However, the important part is the upconverted noise which is present only in the length signal. The QPD and oplev signals show no increased noise from 60-80Hz above the reference traces where no drive is applied
I then compared the multicoherence of those two angular witnesses vs. the multicoherence of the two (linear) witnesses plus their (bilinear) product. Including the bilinear term clearly shows coherence, and thereby subtraction potential, at the upconverted noise hump.
So, it looks like the way I'm generating the bilinear signals and calculating coherence in my code isn't totally crazy.
Not sure if someone is already on this, but the nodus DokuWikis are still down (AIC, ATF, Cryo, etc.)
DokuWiki Setup Error
The datadir ('pages') does not exist, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer
The datadir ('pages') does not exist, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer
As of this writing, the DokuWiki appears to be working.
As you and I suspected, it looks like this was a clusterwhoops with the permissions for the NFS mount. Let's recap what happened in the past 24 hours:
Despite the aforementioned mystery, Zach and I pressed on and tried to diagnose the permissions issue. We found that even if you are logged into nodus or pianosa or rossa or whatever as the controls user, the NFS mount saw us as the user nobody (in the group nogroup). If we created a file on the NFS mount, it was owned by nobody/nogroup. If we tried to modify a file on the NFS mount that was owned by controls/controls or controls/staff, we got a "permission denied" error, even if we tried with superuser privileges.
It turns out this has to do with the vagaries of NFS (scroll down to gotcha #4). We have all_squash enabled in /etc/exports , which means that no matter your username or group on nodus, rossa, pianosa, or harpischordsa, NFS coerces your UID/GID to chiara's nobody/nogroup. Anyway, the fix was to go into chiara's /etc/exports and change this
It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.
I went into local.php and changed $conf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.
I have been looking into the DokuWiki situation, with no great progress so far.
The problem is with authentication. When you try to access the wiki, you get: "User authentication is temporarily unavailable. If this situation persists, please inform your Wiki Admin."
As Evan points out, this goes away if you turn off ACL (Access Control Lists), but---as he also mentions---that just means that authentication is disabled, so the wiki becomes open. All signs point to this being a problem with the authentication mechanism. We use the 'authplain' plaintext method, where the usernames and hashed passwords are stored in a plaintext file.
Evan and I have both done plenty of testing with the config settings to see if the problem goes away. Even if you restore everything to default (but enable ACL using authplain and the existing user file), you still get an error.
I went as far as installing a brand new wiki on the web server, and, surprisingly, this also exhibits the problem. Interestingly, if I install an old enough version (2012-10-13), it works fine. After this revision, they transitioned their authentication methods from "backends" to "plugins", so this is a clue. As a side note, the other wikis on nodus (ATF and Cryo) are running earlier versions of DokuWiki, so they have no problems.
As it stood, our options were:
So, I created a temporary read-only version of the wiki using the aforementioned earlier DokuWiki release. It has a soft link to the real wiki data, but I deleted the user database so no one can log in and edit (I also disabled registration). It can be found at https://nodus.ligo.caltech.edu:30889/wiki_ro/.
I also created a backup of the real wiki as wiki_bak to avoid any potential disasters.
The simplest thing to do would be to just roll the wiki back to this working version, but that doesn't sound so smart. Clearly, it was working with the plugin structure before our snafu, and somehow our fixing everything else has broken it.
The PDFR system has been documented in the 40m wiki and all the relevant information about making changes and keeping it updated have been mentioned.
This pretty much wraps up my SURF 2014 project at the 40m lab.
There was still some residual permissions issue. This is now bypassed and so the ACL is ON and all seems to be back the way it was. I've tested that I can login and edit the wiki.
Some useless knowledge follows here. Please ignore.
After some hours of reading unhelpful DokuWiki blogs, I just put the backup wiki into the local disk on NODUS and then made a soft link to point to that from /users/public_html/wiki/. So this implies that the new NFS setup on chiara is different enough that it doesn't allow read/write access to the apache user on the NODUS/Solaris machine.
Mech Resonance Wiki
I've updated the wiki by trawling the elog for violin entries. Please keep it up to date so that we can make violin notches.
AIC Wiki updated to latest stable version of DokuWiki: 2017-02-19b "Frusterick Manners" + CAPTCHA + Upgrade + Gallery PlugIns
The most up to date pictures of the AP table and ETMX table that Steve took have been uploaded to the relevant page on the wiki. It seems like the wiki doesn't display previews of jpg images - by using png, I was able to get the thumbnail of the attachment to show up. It would be nice to add beam paths to these two images. The older versions of these photos were moved to the archive section on the same page.
ETMX table layout uploaded with beam paths to the wiki.
The pdf file is uploaded into the wiki.
LiYuan has kindly done some Total Integrating Sphere (TIS) measurements on ITMU01 and ITMU02. A summary of the measurement is attached. I uploaded the measurements and some analysis script to nodus at /home/export/home/40m_TIS. I created a Wiki page for the measurements and linked to it from the core optics page.
These TIS measurements look very similar to the TIS of the LIGO optics. Further analysis shows that the scatter loss is 10+/-1.7 ppm for ITMU01 and 8.6+/-0.4 ppm for ITMU02.
In this calculation, a gaussian beam the same size bouncing off the 40m ITMs is assumed to scatter from the mirrors. The error is calculated by moving the beam around randomly with STD of 1mm.
In LiYuan's setup, TIS is measured for scattering angles between 1 and 75 degrees. If we go further and assume that the scatter is Lambertian we can extrapolate that the total loss is 10.9+/-1.9 ppm for ITMU01 and 9.2+/-0.5 ppm for ITMU02.
These measurements complete the loss budget nicely since with the 6ppm loss predicted from the phase maps, the total loss in the arm cavities would be 6+10+10=26ppm which is very close to the 28ppm loss that was measured after the arm cavity optics were cleaned.
I updated the mime.local.conf file for the AIC Wiki so as to allow attachments with the .txz format. THis should be persistent over upgrades, since its a local file.
cosmic rays in cars
Came in, found all front-ends down.
Keyed a bunch of crates, no luck:
Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS
Powered off/restarted c1dcuepics. Still no luck.
Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time.
BURT restored to Nov 26, 8:00am
But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow.
I found the red sea when I came in this morning.
I tried several things.
I'm now going to restart the single front -ends and burtgooey them if necessary.
Everything is back on.
Restarted all the front ends. As usual c1susvme2 was stubborn but eventually it came up.
I burt-restored all the front-ends to Nov 26 at 8am.
The mode cleaner is locked.
Taking a cue from entry 2346, I immediately went for the nuclear option and powered off fb40m. Someone will probably need to restart the backup script.
Backup script restarted.
Looks like there was a power outage. The control room workstations were all off (except for op440m). Rosalba and the projector's computer came back, but rossa and allegra are not lighting up their monitors.
linux1 and nodus and fb all appear to be on and answering their pings.
I'm going to leave it like this for the morning crew. If it
The monitors for allegra and rossa's seemed to be in a weird state after the power outage. I turned allegra and rossa on, but didn't see anything. However, I was after awhile able to ssh in. Power cycling the monitors did apparently got them talking with the computers again and displaying.
I had to power cycle the c1sus and c1iscex machines (they probably booted faster than linux1 and the fb machines, and thus didn't see their root and /cvs/cds directories). All the front ends seem to be working normally and we have damped optics.
The slow crates look to be working, such as c1psl, c1iool0, c1auxex and so forth.
Kiwamu turned the main laser back on.
Looks like there was a power outage.
I checked the vacuum system and judged there is no apparent issue.
The chambers and annulus had been vented before the power failure.
So the matters are only on the TMPs.
TP1 showed the "Low Input Voltage" failure. I reset the error and the turbine was lift up and left not rotating.
TP2 and TP3 seem rotating at 50KRPM and the each lines show low pressur (~1e-7)
although I did not find the actual TP2/TP3 themselves.
One of the possibilities that we see a large low-frequency digital noise is due to Foton. I've checked the SOS coefficients that saves Foton with a Matlab coefficients. I used a 3 order low-pass cheby1 filter cheby1("LowPass",3,0.1,3)
In matlab I generated SOS model using 3 approaches
[A,B,C,D]=cheby1(3,0.1,3/1024) % create SS form
[sos,g]=ss2sos(A,B,C,D) % convert to SOS form
[z, p, k]=cheby1(3,0.1,3/1024) % create ZPK form
[sos,g]=zp2sos(z,p,k) % convert to SOS form
[b, a]=cheby1(3,0.1,3/1024) % create TF form
[sos,g]=tf2sos(b,a) % convert to SOS form
As this is a 3 order filter, in the SOS representation we'll get 2 by 6 SOS - matrix. It is presented below. In each matrix place there 4 numbers - from the Foton file and obtained using these 3 methods.
1 1.0000000000000000 # 0 # 1 # -0.9911172660954457 # 0
1 1.0005663179617605 # 0 # 1 # -0.9911172660954457 # 0
1 0.9999894976396830 # 0 # 1 # -0.9911172660997303 # 0
1 2.0000000000000000 # 1.0000000000000000 # 1 # -1.9909750803252266 # 0.9911175825477769
1 1.9994336820732397 # 0.9994340026283055 # 1 # -1.9909750803252262 # 0.9911175825477765
1 2.0000000000000000 # 1.0000000000000000 # 1 # -1.9909750803252262 # 0.9911175825477765
1 2.0000105023603174 # 1.0000105024706190 # 1 # -1.9909750803209423 # 0.9911175825434912
It seems that smth analog to zp2sos is used in Foton. We can see that due to representation error we have derivations in the 4 and 6 digits for SS and TF forms. This means that a pretty big mistake can run due to digital transforms even using double precision as in the Matlab test.
Alex Ivanov said that he'll fix that single precision problem and in the 2.5 release we won't have any FLOAT variables. Though we still do not understand how that variables declared as FLOAT can cause filter calculations.
In the previous elog we've compared Matlab and Foton SOS representations using low-order filter. Now we move on to high order filters and see that Foton is pretty bad here.
We consider Chebyshev filter of the first type with cuf off frequency 12 Hz and ripple 1 dB. In the table below we summarize the GAINS obtained by Matlab and Foton for different digital filter orders.
We can see that for high orders the gains are completely different (ORDER of 2!!!). Interesting that besides of very bad GAIN, SOS-MATRIX Foton calculates pretty well. I checked up to 5 digit - full coincidence. Only GAIN is very bad.
The filter considered is cheby1("LowPass",6,1,12) and is a part of the bad Cheby filter where we loose coherence and see some other strange things.
I tried to understand what part of the signal is corrupted while passing through a digital straight line without any filters. From here we can figure out what precision is used.
I analysed coherence between C1:SUS-MC3_LSC_EXCMON and C1:SUS-MC3_LSC_OUTMON without any filters between them.
I did the simulation in Matlab using single and double precision. Basically, I took a random signal, made some operations with it to obtain some digital error:
signal1 = randn(1e6, 1); signal2 = randn(1e6, 1); signal3 = signal1+signal2; signal4 = signal3 - signal2;
Then I plotted coherence between signal1 and signal4 that are actually the same signal but signal4 has some digital error. This was done both for single (left red plot) and double (right blue plot) precision.
From here we make a conclusion that C1:SUS-MC3_LSC_EXCMON and C1:SUS-MC3_LSC_OUTMON has single precision. The signal might be converted from double to single in the dtt tools but if dtt works with double precision then the problem is with signals.
In the previous elog we've proved that signals C1:SUS-MC3_LSC_EXCMON and C1:SUS-MC3_LSC_OUTMON are in single precision. Now we try to understand if the precision is lost when the signals enter dtt tools or in the online code. For this measurement we just switch on one of the filters between the signals. By this we add mathematical operations inside the online code. If double precision is used there, then we'll see the same error as before, because the real error is still very small (~10-15) and dtt tools add this 10-7 error. But if the digital error will increase then no matter what kind of precision use dtt, online code uses single precision. At least at some points.
Test 1. cheby1("LowPass",6,1,12)
Test 2. cheby1("Lowpass",2,0.1,3)
Test 3. butter("LowPass",8,10)
Test 4. butter("LowPass",2,10)
We can see that coherence become worse. And longer filter - more digital error. This means that single precision is used in calculations.
We investigated some more the discrepancy between Matlab and Foton numbers. The comparison of cheby1(k, 1, 2*12/16384) was done between versions implemented in Matlab, R and Octave. Filters created by R and Octave agree with Foton.
Also, we found that Matlab has gross precision errors for cutoff frequencies just smaller than used in our fitler, for example cheby1(6, 2*3/16384) fails miserably.
It would be useful to see some plots so we could figure out exactly what magnitude and phase error correspond to "gross" and "miserable".
In order to verify our theory about coherence corruption in linear systems due to the line
if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;
in the /opt/rtcds/caltech/c1/core/release/src/include/drv/fm10Gen.c in the iir_filter function I've changed -20 to other numbers and watched at the coherence input and output of the digital filter cheby1("LowPass", 3, 0.1, 0.5)cheby1("LowPass", 6, 1, 1.5). The sampling rate was 2K. The frequency responce of the filter presented in this figure.
The next plot shows psd and coherence of the signal for different numbers in the if-statement line : 1e-20 , 1e-25, 1e-100.
We can see that for present value coherence between input and output signals is small even for low frequencies. The psd of the output signal is also corrupted because at low frequencies it should have the same psd as input signal. For 1e-25 and 1e-100 we can see that coherence is close to 1 at low frequencies so if-statement does not work and we have a first order transition from bad to good filter performance with discontinious jump of coherence.
However, for 1e-25 and 1e-100 data is still corrupted by the round-off error. Lack of coherence for high frequencies can be explained by the fact that dtt tools use single precision for data analysis and output is too small to plot a right coherence. But the coherence is also not precisely 1 for low frequencies. Actually, it is 0.99 for this aggresive filter. We use double precision in the real-time code but still for such kinds of filters round-off error is present. As wrote Daniel Sigg for Cheby filter: "You need a lot more digits than you may naively suspect. In the 8th order example, the output of each SOS is amplified by ~106. This regardless of the fact that the coefficients are all of order 1. If you require a level of 10-3 attenuation in the stop band, you would have lost 9 digits already. Then, add the fact that you have to do of order 104 subtractions to get from 16kHz to 12Hz, loosing another ~2 digits. On top, the high Q section is probably 10 worse than the others and you lost 12 digits. In a real example this may stack up even worse."
Next we need to figure out what effects does round-off error introduce in the performance of the interferometer.
It would be useful to see some plots so we could figure out exactly what magnitude and phase error correspond to "gross" and "miserable".
To show why Matlab is bad in filtering at small cut-off frequencies we did the same thing in Matab, Octave and R: we've taken the low-pass chebyshev filter of the type 1, order 6, ripple 1 dB, the sampling frequency was 16384 Hz and cut-off frequency varied from 1 to 1000 Hz. Here is the plot for the gain of the zpk model versus to cut-off frequency.
We can see that Matlab's gain shows surprising gains for low cut-off frequencies through for > 100 Hz it is fine. In the next table we compare gain from Foton, Matlab, R and Octave for the same filter. So Foton is also good
I'm trying to get some intuition how digital noise due to quantization shows up in iir filters. I decided to do tests in C using Python to calculate psd and visualize. I've implemented Direct Form 1, 2, "Biquad" and "Low Noise" forms of realization of second-order iir filter from Matt's presentation. There is a typo in the "Low Noise Form" scheme - a1 and a2 gains should be switched. Other then that schemes correctly implement 2 order iir.
The input signal to each filter was a sine wave plus white noise with small amplitude x[n] = sin(2*pi*f*t[n]) + g*random( [-1, 1] ), g << 1, f=1kHz. Sampling frequency was 16384 Hz. All 4 forms implemented 2 order low-pass butterworth filter with cut-off frequency 0.2 Hz
x[n] = sin(2*pi*f*t[n]) + g*random( [-1, 1] ), g << 1, f=1kHz.
For g=1e-2 all implementations work fine. For g=1e-8 when quantization noise increases, all implementations give a lot of noise at low frequencies. I did not notice any significant difference between any of these implementations. I'll try to do more tests to figure out any difference in noise between the forms.
Quantization noise depends on the architecture of the processor, compiler and what not. But I do not think this can give a huge difference in results. We need to understand carefully digital noise during PSD estimation and all operations done at Matlab or Python.