View Single Post
  #6 (permalink)  
Old 03-06-2007, 10:43 PM
DSP-Newbie
Guest
 
Posts: n/a
Default Re: Time domain convolution in a real-time situation

[email protected] wrote:

>
> Explicitly padding the input signal with zeros like this will work.
> However, note that you're essentially delaying the input signal by
> length(H) samples, so your output signal (even before you see any
> transients) will also be delayed by length(H) samples.
>


I am aware of that, but its is not a problem; the delay is the same for
all samples.



>> My problem now was, which part of Y[] should I extract and use?
>> After much and trial & error and some hair-pulling, I finally found a
>> intuitive solution that actually works:

>
> -snipped-
>
> I forgot to ask before: why do you want to discard the transients? The
> filter "startup" time is valid data, and occurs as your input signal
> gradually fills up the delay lines that feed each filter tap.


Perhaps I have not explained my problem clearly.
I have set the soundcard to sample at 11.025 KHz, and to report the
samples in blocks of 2048 samples, so I have to process about 5
samples/sec.

Each of these samples - after filtering, envelope detection, PLL bit
sampler etc... - represents a number of bits, not necessarily a *whole*
number of bits, which I have to cobble together block by block to
reconstruct the original synchronous bitstream.

Now, if I apply the algorithm as found in the book for each incoming
datablock, I will have a startup transient for *each* block. There is
no history from previous blocks. This results in repeating bit errors.

But, as I mentioned in my previous reply, the zero-padding etc. now
made it working correctly.
BTW: the filter performs **tremendously** well; I can now decode
almost inaudible signals totally buried in the noise.


[snip]
> Remember, all you're trying to do here is implement the convolution
> sum, nothing more.


Sure, but I've had a hard time with it >:|

Thanks again for the explanations Jason, it is appreciated!


Reply With Quote