Displaying reports 68501-68520 of 83224.Go to page Start 3422 3423 3424 3425 3426 3427 3428 3429 3430 End
Reports until 13:18, Tuesday 18 November 2014
H1 PEM
filiberto.clara@LIGO.ORG - posted 13:18, Tuesday 18 November 2014 (15134)
H1 PEM Cabling at EX
This morning we disconnected all DC power to PEM electronics (SEIS, TILT, MAG, MIC ect) and connected them to the dedicated PEM power supplies. This should start cleaning up some of the clutter in the VEA, example power supplies sitting on the floor used for temporary power. Everything should be up and running, but let me know if we missed something.
H1 PSL
gabriele.vajente@LIGO.ORG - posted 12:39, Tuesday 18 November 2014 (15133)
Beam dumps in IOT2R

[Sudarshan, Gabriele]

To understand why intensity noise was worse than usual, we had a look again at the beam dumps we installed yesterday on the two beam coming out into IOT2R

After yesterday's realignment of the main beam, the two dumps were no more in a good position. To be more precise: the two beams coming into the enclosure are very close to the edge of the periscope upper mirror; one of the beams is hitting the bottom mirror in a reasonable position but was partially missing the beam dump; the other beam was hitting the edge of the mirror and the mount. Therefore, we moved the first beam dump to a better position, and we dumped the second beam before it hits the periscope bottom mirror. See attached picture

This improved the intensity noise, but we can still see a bit of 18 Hz peak. 

Images attached to this report
H1 PSL
gabriele.vajente@LIGO.ORG - posted 12:33, Tuesday 18 November 2014 (15132)
Crazy intensity noise tonight

Intensity noise was very high this morning, see the red trace in the first attached plot. It started to be like that yesterday night, during some of the locking tests. After some investigations, it turned out to be due to the LSC correction sent to MC2 and generated by the ALS. After switching it off, intensity noise returned to reasonable values, even though a bit larger than usual, inicating a not optimal alignment of the IMC.

Another pecualir thing is that yesterday night, while IM4 ws moved, the power on IM4_TRANS changed as well. This is a bit unexpected...

Images attached to this report
H1 SEI
hugh.radkins@LIGO.ORG - posted 12:20, Tuesday 18 November 2014 - last comment - 13:42, Tuesday 18 November 2014(15131)
WBSC1 ITMY HEPI Local <> Cartesian Matrices Corrected and new controllers implemented---errant model behaviour requires restart--Guardian restore RX & RY?

Looked like commissioners were still working on the alignments so I held off on doing similar to WHAM3.  So, I went to the ITMY which also needed some matrices corrections.  These corrections required new controllers so I just went with Hugo's standard controllers and some mods to those, see 15112.

I brought down the HEPI at ~0805pst, the ISI watchdogs tripped very soon after.  About 0813 I loaded the new matrices and attempted to restart the HEPI after adjusting the X dof Target Location.  The RZ loaction did not change as the matrix errors I'm correcting are amplitudes in X & Y and the output matrix which was all 1s.  Did you notice I forgot to mention loading the new controllers (required with changed matrices?)  Well I did forget them, so then I prepared and loaded the new controllers and tried again.  Okay, not so good...the vertical dofs are tripping quickly when the boosts turn on.  Well, if you remember from my yesterday's alog, I elected to leave the vertical controllers at 5hz UGF.  So I lowered them to 2hz like all the horizontals (I hadn't actually tried the horizontals yet, but I later did and they were fine.)  Still the verticals blow up quickly when the boost is engaged.  So, I continued and reduced the zero of the boost from 1.0 to 0.7hz as I did with the horizontal dofs.  But, still no luck so I lowered them to 0.5hz and again no good.  Alright, I tried the horizontals and they worked, I did the verticals manually and they are fine without the boosts.

Next I set up to do an open loop, this would reveal if my controller's matrices did not match my installed matrices.  Well, the boosts would not engage at all for Z RY or VP!  We attempted all sorts of things like resaving the file from foton, confirming the turn on method, comparing the boosts, putting the boost in another module (where it did turn on.)  Finally, restarted the model, and HEPI isolated first attempt (3 hours later!)

So, the new matrices and new controllers work--why did these filter modules stop engaging properly and sending some wacko spike into the output--they would not have done any harm if they actually weren't doing anything?  I thought about reverting the controllers back to where I started to see if at first it was actually my boosts but the the shape changes were actually quite minor: the gain peaking dropped from less than 3 to less than 2, and phase margin went from ~30 to ~50 degrees.  Too little time so I didn't change them back.  So unless my controllers were very bad to start and the repeated loading of fotons and tripping the watchdogs did something, the first attempt with the non-updated controllers must have done something to the filter module/model, or, it was a problem waiting to happen.

I noticed that the Guardian was restoring the RX & RY Target Location.  I'm confused with that.  I thought we were only restoring RZ everywhere, with Pitch at the ends, and X on ITMY (initial alignment.)  I'll research the history and maybe I'll learn something but again, I did not think we were restoring these.  It might make sense to do so as these are the tilting of the platforms but that is another issue.

I'll put an updated image of the controllers in shortly.

Updated safe.snap and latest foton file filed in the svn.

Comments related to this report
hugh.radkins@LIGO.ORG - 13:17, Tuesday 18 November 2014 (15135)

Here are the controllers I loaded this morning--pretty much the same as yesterdays but with the verticals UGF lowered from 5 to 2hz and the zeros of the boost lowered from 1 to 0.5hz.

Non-image files attached to this comment
hugh.radkins@LIGO.ORG - 13:24, Tuesday 18 November 2014 (15137)

A look at the optical lever of the ITMY would suggest the alignment is returned to whense it came.

hugh.radkins@LIGO.ORG - 13:42, Tuesday 18 November 2014 (15139)

Guardian holding RX & RY: Yes

from 25 July,  I log why--we added the ACB after initial alignment and plan to adjust the large HEPI springs to do away with this need, someday.

just for the record--with the amplitude change of the X & Y dof values in the local to cartesan matrix, the target position of the X hold, changes from 300000 to 600000.

Here attached is the trends showing all the wiggles and waggles and also showing the OpLev returning to whense it came to within a urad.

Images attached to this comment
H1 PSL
gabriele.vajente@LIGO.ORG - posted 12:04, Tuesday 18 November 2014 (15130)
ISS model and medm screen odifications

[Sudarshan, Gabriele]

Model has been recompiled and restarted.

H1 CDS
james.batch@LIGO.ORG - posted 11:58, Tuesday 18 November 2014 (15129)
Installed recompiled version of TDS
For Ubuntu workstations, a new version of TDS tools have been installed.  Following a complaint that ezsfft was failing, it was determined that the tool needed to be recompiled since libraries ezsfft depends on have been updated.

Note that the documentation states that ezsfft is obsolete, tdsdmd should be used instead.

The ezsfft no longer core dumps, but it doesn't seem to work, either.  The tdsdmd tool does appear to work, so it should be used instead,

The ezlockin script has been changed to use tdsdmd and tdssine instead of ezsfft and ezsine.  I have no idea if the script still works, there's no test case for regression testing.
H1 CDS
james.batch@LIGO.ORG - posted 11:35, Tuesday 18 November 2014 (15128)
User environment setup scripts modified
This will affect all users -

The user environment setup scripts have been changed to include some common aliases that may be useful to users. 

alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

alias target="cd /opt/rtcds/lho/h1/target/"
alias t="cd /opt/rtcds/lho/h1/target"
alias chans="cd /opt/rtcds/lho/h1/chans"
alias h1="cd /opt/rtcds/lho/h1"
alias userapps="cd /opt/rtcds/userapps/release"

alias latest="ls -alt|head"

alias scripts='cd /ligo/lho/scripts'
alias data='cd /ligo/lho/h1/data'
alias medmdir='cd /opt/rtcds/lho/h1/medm'
(there's more than these...)

If an individual user wishes to redefine one of these aliases, they can do so by editing the ".bashrc" file in their home directory to include a different alias command AFTER the line "source /ligo/cdscfg/stdsetup.sh"

A complete list of aliases can be found by entering the "alias" command with no argument (in a terminal window, of course).

I have also changed the setup scripts to recognize a different operating system, but this should not affect any users and is in place for testing candidates for the next control room computer OS.
H1 CDS
cyrus.reed@LIGO.ORG - posted 11:17, Tuesday 18 November 2014 (15127)
Workstation Updates
I've run the latest updates on all the CDS workstations and rebooted them as part of Tues maintenance.  (opsws6,9,10 are pending reboots as they were in use this morning.)
H1 PSL
jeffrey.bartlett@LIGO.ORG - posted 11:05, Tuesday 18 November 2014 (15125)
Diode Room Crystal Chiller
Add 125ml water to Diode room crystal chiller
H1 IOO
gabriele.vajente@LIGO.ORG - posted 09:54, Tuesday 18 November 2014 (15121)
Beam wandering on IMC WFS

The attached plot shows a trend of 60 days of beam spot position on the IMC WFS. Excluding two manual re-centerings of the beam (I'm sure about the last one, since I did it) the beam is not moving significantly on the WFS. The peak to peak motion is at most 0.1-0.2 in units of QPD normalized signal, which corresponds to 0.06-0.12 fraction of beam radius.

The position looks quite stable over long periods.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 07:46, Tuesday 18 November 2014 (15119)
CDS model and DAQ restart report, Monday 17th November 2014

model restarts logged for Mon 17/Nov/2014
2014_11_17 14:27 h1fw1

one unexpected restart

H1 ISC
alexan.staley@LIGO.ORG - posted 01:56, Tuesday 18 November 2014 - last comment - 11:15, Tuesday 18 November 2014(15115)
Recovering input alignment part duex, DRMI + arms off resonance

(Sheila, Evan, Keita, Nic, Kiwamu, Alexa)

We locked the IR to the x-arm and adjusted PR3 until we achieved the good IM4 alignment specificed in alog 15109. We adusted the HAM3 picometers to restore the ALS green trans beam on ISCT1; I used the camera reference position that we had previously found (alog 15072) and ensured a high build up in TRX. We then aligned MICH on the dark fringe and PRM using PRX lock. Not surprisingly, we had to move PRM a lot.  SRM was also aligned, with SR2 and SR3 in the old configuration. Attached is a screen shot with the current alignment values. The POP sled was aligned as noted in Keita's alog 15116.

We were able to lock PRMI on the sideband, and acheived 260 cnts build up. Our best build up had been between 260-399 cnts as seen by a trend Keita had taken over the span of 3 weeks. We feel okay about our current build up. 

Sheila and Evan marked a new IM4 trans beam on the wall in the LVEA. It seemed the beam hadn't moved all that much from the old position (from June); maybe a few millimeters.

We adjusted the ALS alignment on ISCT1; we got 0 dBm for COMM beatnote, and 6 dBm for DIFF beanote.

ALS DIFF locked right away. The UGF was 7 Hz, with 70 deg phase margin. The in loop RMS was 0.2e-3 um/srtHz at 0.1Hz. This was with feedback to ETMX only.  We then tried feeding back to both ETMX and ETMY L1 stage with Jeff's new EY L1 L2P filters engaged (FM6, FM7); however this did not work. The L2P filters output a huge value 1e+20 and we saturated the DAC immediatly. FM7 has a step response of 10^18 ! Also, are we supposed to leave Arnuads invP2P filter engaged? We must have rung up a mode around 10 Hz. Nic and Kwamu fixed this (see their alog 15118).

We locked DRMI 1f with the ASC wfs engaged. POPAIR18 measured 343cnts, and ASAIR90 measured 5731. It appeared to be the best DRMI "moment of [Sheila's] life." DRM1 1f lock time Nov 18, 2014 6:07 UTC. We transitioned to 3f flawlessly at ~ Nov 18, 2014 6:12 UTC. We lost lock at Nov 18, 2014 6:14 UTC.

Then we tried locking DRMI with the arms 500 Hz IR off resonance. At first, the DRMI alignment did not look as good; when we engaged the wfs the build up increased dramatically but we would lose lock when the build up got high. We deduced that the gain of the loops had to decrease with the precense of the arms. We reduced MICH gain from 5 to 4 to obtain a 15 Hz UGF. PRCL we reduced from 22 to 11. At some point the alignment looked good and the lock was stable for a bit, but we lost lock trying to measure the SRCL loop gain.  We got tired...

Images attached to this report
Comments related to this report
lisa.barsotti@LIGO.ORG - 10:41, Tuesday 18 November 2014 (15122)ISC
"We lost locked at Nov 18, 2014 6:14 UTC"

GPS 1100326478

Something bad happens to MICH (-0.1s in the plots, different zooms). 
Images attached to this comment
alexan.staley@LIGO.ORG - 11:15, Tuesday 18 November 2014 (15126)

Sorry for the typo's -- deux*, lost lock**

Thanks for the plots Lisa. After this lock loss, we had another stable lock that only broke because we took it down. But it seems like we should take a look at MICH. 

Also, Jeff told me that BOTH EY L1 L2P FM7 (UIM_InvP2P) AND P2P FM1 (InvP2P), should be turned ON. This is the configuration we used last night when we tested his new filters, but we had been unsure whether this was correct or not.

H1 SUS (ISC)
nicolas.smith@LIGO.ORG - posted 00:34, Tuesday 18 November 2014 - last comment - 13:45, Tuesday 18 November 2014(15118)
Damping ETMY high frequency bounce mode

(kiwamu, nic)
There was a very large ~10Hz spike in the ALS DIFF control signal. The signal was also visible in the optical lever signals of both ETMs, and they looked coherent with each other

We were only feeding ALS DIFF to ETMX, so Kiwamu hypothesised that this indicated that the source of the motion was ETMY and the DIFF loop was impressing motion onto ETMX.

We waited for a long time for the mode to damp itself, but it was very persistent.

We weren’t sure what caused the mode to ring up, it may have been the bad L2P filters that caused the DAC to saturate. The only drive signals on ETMY were OSEM and optical lever damping. So we also put a notch in the OL damping loop in case that was ringing it up.

Finally we decided to just damp the mode using the “DARM ERR DAMP FILTERS” on the SUS screen (thanks LLO!). Using the H1:SUS-ETMY_L2_DAMP_MODE1_INMON filter bank and with the output matrix feeding to ETMY L2 pitch, we put a narrow bandpass around 9.73Hz, as well as a velocity damping filter. Then we just varied the output gain until we could see the mode changing amplitude. Then we flipped the sign and further increased the gain until the mode was clearly ringing down. It had a time constant of about a minute. Once we had a good gain, we dumped the gain into a filter module.

Now the correct gain in H1:SUS-ETMY_L2_DAMP_MODE1_GAIN to damp the mode is -1.0.

Comments related to this report
keita.kawabe@LIGO.ORG - 09:12, Tuesday 18 November 2014 (15120)

Bounce mode coupling (to the length) is a factor of 80 larger at EY than at EX due to local gravity VS IFO z-axis angle (alog 14876).

Unlike roll, bounce mode should have a predictable, consistent phase relation to the length, i.e. bounce up = longer arm.

You can see the bounce mode rung up by looking at top mass V (attached) for EY, but not for EX.

This should mean that the bounce could be damped by a factor of few using the top mass (which might or might not be able to stop the ringing up).

Also, if we have a path to route the LSC signal to the top V, we should be able to damp the mode easier (as in easy filter design) than feeding back to L2 stage.

Images attached to this comment
nicolas.smith@LIGO.ORG - 13:45, Tuesday 18 November 2014 (15140)

Just in case my elog wasn't clear.

We found the mode rung up while locking ALS DIFF. We were not sure of the reason for it to be rung up.

We were able to damp it using the DARM ERR damping filters that feed to L2, these had not been used in the past. We commissioned them for the first time. Our initial guess of the sign was wrong (50/50 chance) so we flipped it to damp the mode.

Once having the new filters and gain, the mode was damping. We don't yet know if the coupling is stable (requiring retuning) over long time scales. I think LLO has seen that these are stable.

The error signal is DARM ERR so it can only be turned on when on ALS DIFF or full lock. With ALS DIFF, the gain that gives good damping is -1.0.

H1 SUS
betsy.weaver@LIGO.ORG - posted 14:29, Monday 17 November 2014 - last comment - 14:08, Wednesday 19 November 2014(15107)
3IFO QUAD Q7 Phase 1 testing

A second round of testing on the all-metal 3IFO QUAD unit Q7 is attached.  After we saw a few cross coupling terms and struggled with coherence in the prior measurement set, we made a few adjustments to the QUAD mechanics.  However, readjusting the lacing cabling and retuning the sensor mounting tablecloth seemed to not help much.  There is still L and R bleeding into P on the reaction chain.  We were able to improve the coherence by building a fort around the test stand however.  The main chain looks to be in pretty good shape though.

 

The first attachement below is of Q7 with damping on and off.

Non-image files attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 14:31, Monday 17 November 2014 (15110)

The attachment below is of the Q7 (pink traces) undamped TFs compared to the 3IFO Q6 and Q8 units.

Non-image files attached to this comment
travis.sadecki@LIGO.ORG - 11:04, Tuesday 18 November 2014 (15124)

Screenshots of damping filters for DC offset diagnosis.

Images attached to this comment
travis.sadecki@LIGO.ORG - 14:08, Wednesday 19 November 2014 (15165)

Spectra for all stages of Q7 attached.  Note that the L1 and L2 stage OSEMs are not aligned and centered.

Non-image files attached to this comment
H1 SUS (ISC)
jeffrey.kissel@LIGO.ORG - posted 23:31, Thursday 13 November 2014 - last comment - 22:51, Monday 17 November 2014(15049)
Potentially New H1 SUS ETMY UIM (L1) L2P Filter Design
J. Kissel

I've measured new transfer functions necessary redesign of the H1SUSETMY UIM (L1) DRIVEALIGN frequency-dependent decoupling filters for L2P and L2Y. For the impatient, the last page of the last attachement shows a comparison between the proposed new design and the old, currently installed / in-use design. I have *not* installed this filter because I'd like to discuss the results with commissioners tomorrow morning (and it'll take me some time to resurrect quack to get these installed). In fact, this may argue for us to indeed just copy over ETMX's filter.

Details:
-----------------------------------------
I attach the measurement results (see 2014-11-13_H1SUSETMY_L1_drivealignfilters_rawdata.pdf), but the raw templates can be found here:

/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/SAGL1/Results/Data/
2014-11-13_H1SUSETMY_L1_L2PY_WhiteNoise_ReactionChainTest.xml
2014-11-13_H1SUSETMY_L1_L2PY_WhiteNoise.xml
2014-11-13_H1SUSETMY_L1_P2PY_WhiteNoise.xml
2014-11-13_H1SUSETMY_L1_Y2PY_WhiteNoise.xml

Not that I drove through the TEST filter banks (instead of having to turn off all the existing filters in the LOCK and DRIVEALIGN banks), and made sure that optical lever damping was OFF, and local damping was the LLO design as described in LHO aLOG 14959.

I focus this entry solely on L2P, but the data exists for an L2Y filter if ever needed. in the first four pages, Pink curves are the current measurement, and black curves are what were used in the original design of the previous filter by Arnaud (see LHO aLOG 11832). The encouraging fact is that the data supports exactly what we'd model from the change in damping loop filter design (see green traces on pg 5 of first attachement to LHO aLOG 14959). As an aside -- just because Betsy made me think of it while chasing down slider values -- what effect does reaction chain alignment have on these off-diagonal, lower-stage transfer functions? One might guess that if the L2P cross-coupling isn't something fundamental but a result of dirt alignment affects between the coils on the reaction chain and the magnets on the main, then one would see a change in the L2P transfer function with different alignments of the reaction chain. The good news is that is doesn't have any effect -- see the last page of 2014-11-13_H1SUSETMY_L1_drivealignfilters_rawdata.pdf. I compare the same transfer function for 4 different reaction chain alignments. They still have the old dead-reckoned calibration factors installed, so we know they're not exactly [urads] but close enough for the scale of these offsets used; they use up about 1/2 the DAC range.

As far as the design goes, I used the same transfer function fitting routine and filter generation software suite that (I think) Arnaud used, namely the function
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/FilterDesign/Scripts/Length2Angle_decoupling.m 
which is essentially a wrapper around the function,
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/happyVectfit.m 
which Keita's wrapper around the function,
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/vectfit3.m
All tweaking of input parameters to the fitting routine, and plots were made using the overarching script
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/SAGL1/design_H1SUSETMY_L1_L2P_20141113.m

Notable key additions to the design software -- a computation of the final filter's impulse response, as well as a comparison to the previous design.

As I know Arnaud had struggled, I struggled to find a fit with which I was really happy, namely because we all *know* that the L2P transfer function should fall off as some large power of frequency (again, see the models of these TFs on pg 5 of LHO aLOG 14959), but I can't find a set of parameters happyVectFit / vectfit3.m that allows for such a roll-off at high frequency. Indeed, the height of the final flat part of the L2P fit transfer function directly determines the high-frequency gain of the decoupling filter, and directly impacts the impulse response time. I settled on a filter that does a poor job at reproducing the > 2 [Hz] behavior of the L2P measurement, BUT I think it's OK because
(a) the small magnitude of the high-frequency causes a significant drop in impulse response time, and
(b) At the UIM, we're typically driving below 2 [Hz] -- especially if the crossover remains at 0.9 [Hz] as quoted in LHO aLOG 15025, so the accuracy of inversion is not so critical. Though I didn't find any design aLOGs, this seems to have been the philosophy behind the ETMX UIM L2P filter because it ends up looking strikingly similar.
I should say also that having to tune the uncertainty tolerance, the order (i.e. number of poles) in the filter, the tolerance for when to throw out adjacent poles and zeros, the frequency range over which to fit -- all free parameters into happyVectFit.m -- as one has to do to get what one wants in the end really destroys the advantage of automating the fitting process. If only there was a better way...
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:55, Friday 14 November 2014 (15076)ISC, SEI
I've installed the filter into H1:SUS-ETMY_L1_DRIVEALIGN_L2P filter bank, in FMs 5&6 via autoquack. 

HOWEVER
(1) I have not tested the filter performance with transfer functions or step response
(2) I've split the L2P and (invP2P * rolloff) into two filter banks. Even with the rolloff, the (invP2P * rolloff) filter has more zeros than poles, so foton has added a whole bunch of high-frequency poles to compensate. Though the *total* filter's -- L2P * (invP2P * rolloff) --  number of poles is equal to the number of zeros, I think the high-dynamic range, zero pole, cancellation between the two filters isn't working out. This is resulting in a HUGE calculated impulse response, which may or may not be real.
(3) This is my first time using quack to install Matlab filters into foton in a *really* long time, so I'm nervous of its functionality.

I attach a series of comparisons with ETMX's filter. The bode plot, in the frequency band we care about (pgs 1 and 2) seems reasonable. Both ETMX and ETMY have some high-frequency garbage in their impulse response, but the overall amplitude of the impulse response in ETMY is many orders of magnitude larger than that of ETMX (!!!). Further, taking the transfer function out well beyond the Nyquist frequency, we see that they behave significantly differently at the Nyquist frequency (~7 [kHz]).

As such, I'm still entirely unsure that this new filter gunna work, and may require further tweaking.

Anyways, these are installed in 
FM5 "UIM_L2P"
FM6 "UIM_invP2P"
and should be turned on TOGETHER, with no other filters engaged in the module, if one would like to be bold and try it over the weekend.

P.S. in case you've forgotten, when you autoquack in a filter who's name has a space in it, and you try to load the new filter coefficients, Foton will hate you. You will, at least, get a nasty-gram on the GDS_TP screen's filter message, ${IFO}:FEC-${DCUID}_MSG saying "bad filter coeff definition on line 259 in .txt," pointing you to the exact line of the problem. So with Jim's confirmation that "Oh yeah, you DEFINITELY don't wanna do that." I changed spaces to underscores and all worked fine.
Non-image files attached to this comment
nicolas.smith@LIGO.ORG - 22:51, Monday 17 November 2014 (15117)

These filters did indeed run away and saturate the DAC. (The EPICS values were even showing “-Inf,” I’d never seen that before). I don’t think we can get away with more zeros than poles in a filter module, even if they are compensated by some other module.

I took the two filters (FM6 and 7) and viewed them in the foton “Multiple” mode, then I took the output in the “Alternate” box of foton and copied that into FM10.

When I tried this, instead of a huge mess I got a nice step response according to foton, and the frequency response was the same as the two original filters. As seen below (new is red, old is blue):

foton
However, stupid foton wouldn’t save the filter (but gave no error message). In the end, I had to take this “Alternate” output and split it up into two filters, being careful that each had more poles than zeros. This allowed me to save the foton file and load the filters into the frontend. I tested that the impulse response behaved nicely by putting an offset into the filter bank.

The two filters are in FM5 and FM10. Their names reflect my frustration.

Images attached to this comment
Displaying reports 68501-68520 of 83224.Go to page Start 3422 3423 3424 3425 3426 3427 3428 3429 3430 End