How can I eliminate the time delay pruduced after fitering, and line up with the original signal

[altenbach]

Each filter has a known delay that can be determined from first principles. Instead of jumping through flaming hoops (e.g. with reversing and refiltering, which will cause additional filtering!), you can just change t0 of the filtered signal. Everything will align, but the filtered data will appear with a time delay compared to the live signal.

If you do filtering in post processing where all data is available, things are much easier to keep aligned. I often just do a convolution with a centered kernel.

[Ben]

Bobv wrote;

"

it amounts to averaging an N-point filter advanced by N/2 points with another N-point filter retarded by N/2 points -- you can work out the math if you are sufficiently curious).

"

Which was what I was getting at when I said the delay was a function of the order of the filier.

Christian wrote:

"

Instead of jumping through flaming hoops (e.g. with reversing and refiltering, which will cause additional filtering!), ...

"

While I suppose there are filtering methods where that may be true and it was my first instinct when fat-fingered my way through that the first time. But I was surprised and pleased that the second time through did not make a difference aside from the time shift. For filtering methods that involve removing certain frequency components, one they are removed that are gone and the second pass has no effect beyond the time shift.

in the case of the question poised in this thread, I still think the most simple fix is to filter both signals the same way. Done!

Re: Running it backwards through the filter...

Spoiler

In my case I was developing the back-end code for a "just in time" delivery system that monitored the amount of product in silos and ensuring that new product was on a truck and headed to the silo before it ran out. Just doing level checking was not enough because there changes in production lines that suddenly demanded more of a product than had previously been used.

The detector used in the silos were not under my control. I had to make do with some rather funky measurements that were quite noisy in some cases. My customer want to take care of that by applying a filter that could be adjusted for each silo. Nice idea but...

When applying the filter, I got better readings but I lost information about what was happening NOW. I could tell what happened yesterday but not today.

The human eye can look at a plot and guess were the next data point was going to end up. To do that with code ....?

So going with what I thought humans did I reflected that data set (in both time and magnitude) about the last data point I had acquired. Run it through a filter first forward and then back again and then toss the portion of the plot that was added when I reflected plot. This gave me a reading that was as current as possible and was a decent guess at what was happening.

Admittedly the idea breaks down if "now" is an inflection point but in general worked rather well.

That application is still running today and many people have benefited by that approach. It will not pass muster as legal under the laws of weights and measures in all states, but it does serve well to alert a customer rep to take a look at the silo levels at the right time.

Ben 

[altenbach]

---

@Ben wrote:

But I was surprised and pleased that the second time through did not make a difference aside from the time shift.

---

If you would add the word " ... did not make a significant difference ..." I might agree with you depending on the amount of filtering and the level of acceptable error. Just getting rid of noise from an analog signal is relatively insensitive to the exact filtering parameter, but mathematically your statement is definitely not true. Of course you could account for the double-filtering by slightly lessen the filtering in each direction (I think you were saying that). There are also more edge effects. Instead of only the first N point being slightly off, now we have the first and last N point off.

If we have all the data, we can filter once with a convolution (or ither method) that does no change the alignment. If we need to filter ptbypt, we don't have that luxury ( ... and cannot apply the "reverse" trick anyway.).  Here you would account for the shift by changing t0 of the filtered signal as I already suggested.

In any case, we don't need to guess. A simple experiment would be to compare the central parts of a singly filtered but properly time-shifted signal with a filter-reverse-filter-reverse signal using the same filter parameters. Anybody done that?

[PolymerTim]

The OP asked how to match up filtered data with the raw signal.  The filtering will lead to an inherent time delay, but since the delay, in this particular case, is quite short, I recommend, as altenbach does to simply adjust t0 of the filtered data to allow them to match up.  From the OP screenshot, I estimate this will cause less than a 1 second delay in the filtered data.  If this delay is not acceptable, then a different type of filter should be considered.  You can synchronize the filtered and raw signal on a display, but you can't make up for lost time introduced by the filter.

If the intention is to filter both inputs and show only filtered data, then of course it is much simpler to use the same filter on both signals to give the same delay.  Maybe that is where the OP is going, but it is not what he asked.

I agree with altenbach that double filtering is a wasteful way to adjust a time delay.  It will work, but it can have an impact on the data.  Whether it does or not depends on whether the data contains frequencies close to the filter cutoff.

[Ben]

We agree Christian.

See this thread where CC did some testing on the topic of reflecting and filtering.

Ben