Reply by Viognier October 19, 20062006-10-19
I should mention that the mfilt version of filter is part of the Filter
Design Toolbox product.

-V

Reply by Viognier October 19, 20062006-10-19
Hello Jerry,

The 'mfilt/filter.m' function takes as a first argument a multrate
filter object. This object preserves state between invocations of the
function if the 'PersistentMemory' property is set to true.

Using FDAtool, you can create a multirate filter and generate the m
file. In the m file you can see how this multirate filter object is
created via the command line. This object can be passed to the
mfilt/filter function repeatedly.

I am not sure but I think this will help you out so that you do not
need to reinvent the bookkeeping. Do a help on 'mfilt/filter'

BTW I am using release 2006b.

Hope this helps you out.

-V

Reply by Jerry Wolf October 18, 20062006-10-18
Peter Boettcher wrote:
[snip]
> It seems like a bit of a waste, but since the internal structure is > FIR, you just need some overlap between frames. Overlap-add and > overlap-save are two different techniques to reassemble the correct > output from independently computed filtered blocks. > > I assume your block size is large compared to the number of taps in > your filter?
Yes it is. Thanks for the hint; haven't done overlap-add/save in a long while, but I'll have a go at it. cheers, jerry
Reply by Peter Boettcher October 18, 20062006-10-18
"Jerry Wolf" <jjwolf22@verizon.net> writes:

>> The problem with upfirdn is that it does not return filterstates at the end >> of the processed block.
[snip]
> So it appears that upfirdn had such a capability in R12, but it's since > been removed. > > Rats. I too need such a capability, to resample signals that are too > large to process in one piece, so I need to be able to do it in > adjacent blocks, and neither resample nor upfirdn support this.
It seems like a bit of a waste, but since the internal structure is FIR, you just need some overlap between frames. Overlap-add and overlap-save are two different techniques to reassemble the correct output from independently computed filtered blocks. I assume your block size is large compared to the number of taps in your filter? -- Peter Boettcher <boettcher@ll.mit.edu>
Reply by Jerry Wolf October 18, 20062006-10-18
Back in Apr 25, 2004, MC Canzee posted a query in comp.soft-sys.matlab
that said (in part):

> i want to resample frame-based. > Therefore i need a filter, that returns filterstates. > Like e.g. [y,zf] = filter(b,a,x,zi) does.
> But due to resampling process this filter should be multirate to be > efficient, like e.g. upfirdn(); > The problem with upfirdn is that it does not return filterstates at the end > of the processed block.
He went on to say that he'd found a webpage showing the MATLAB documentation on upfirdn from MATLAB Release 12, which describes just such a calling option: "[yout,zf] = upfirdn(xin,h,...,zi) specifies initial state conditions in the vector zi. The size of the initial condition vector zi must be the same as length(h)-1, the number of delays in the FIR filter. When xin is a vector, the size of the final condition vector zf is length(h)-1, the number of delays in the filter. When xin is a matrix, zf is an matrix with (length(h)-1) rows and (size(xin,2)) columns." So it appears that upfirdn had such a capability in R12, but it's since been removed. Rats. I too need such a capability, to resample signals that are too large to process in one piece, so I need to be able to do it in adjacent blocks, and neither resample nor upfirdn support this. Does anyone know of an efficient way to do this in MATLAB? cheers, jerry wolf spaceflight systems corp.