Few taps Filters for FSK?

Does anyone have any suggestions for an IIR or FIR band pass filter that
will isolate the two tones of an FSK signal which an integrate and dump
scheme can then be applied to?

I need to minimize the delay since this FSK signal comes from scanned radio
frequencies. I need to detect the signal fast enough so the scanning can be
stopped.  The more taps, the greater the delay and the slower the scan
cycle.

Brian

"Brian Reinhold" <breinhold@comcast.net> wrote in message
news:jvCLb.7309$5V2.11137@attbi_s53...
> Does anyone have any suggestions for an IIR or FIR band pass filter that
> will isolate the two tones of an FSK signal which an integrate and dump
> scheme can then be applied to?
>
> I need to minimize the delay since this FSK signal comes from scanned
radio
> frequencies. I need to detect the signal fast enough so the scanning can
be
> stopped.  The more taps, the greater the delay and the slower the scan
> cycle.

Brian,

Didn't you like the answers you already received?
You haven't given us any real parameters so being more specific is
impossible.
Real numbers would be helpful.

That said: it is unlikely that a FIR filter will be short enough to suit
you.  Over 100 taps is likely.
A 3-stage of biquads IIR filter may do the trick (15 coefficients) - as I
mentioned before.

The objective seems to mix two objectives together:
1) Determining that the FSK signal exists at all in a scan process.
2) Determining which of the FSK tones is being transmitted.
Do you need to do both at the same time?  Why?  Wouldn't tone discrimination
be done after figuring out that a signal exists in the scan process?  Surely
you don't expect to scan and when the scan stops to have a complete FSK
message decoded for some arbitrary time.....
Might the filter be wide enough to grab the whole FSK spectrum for the scan
first?  Why associate that with the detection process?
If the filter is narrow enough to discriminate between tones then can you
effectively scan with the same filter?
Here's why I ask:
If a filter is very narrow then it will have a long transient response
time - it will take some time to settle to a steady state value.  Scanning a
narrow filter can yield NO output because it isn't given enough dwell time
(dwell time longer than the transient response time) at any frequency.  In
fact, discussing just what a scanned filter like that *is* will be an
interesting discussion here.
Similarly, how do you guarantee that one FSK tone would be captured if a
narrow filter is used?  For example, scan up in frequency ... when the scan
is nearing the FSK spectrum the tone is at the high end, when the scan is in
the low end or middle of the spectral width there's no tone.  Then, the tone
switches to the low end ... when the scan gets to the high end, there's no
tone there either.  So, no scan alert.  Well, there could be a transient
that's detected but that's a "could be".

See how speculative it becomes without numbers?

Fred

Now I see the problem.  I never thought my first message got posted.  So I
posted it again today.  And I thought it didn't get posted either but I
couldn't beleive it would happen again.  But now I have found it.  I have
always had the messages ordered by time, but somehow they have gotten
ordered by something else, and my posts were way down the list.  It was a
stupid mistake; also enhanced by coincidence that the messages appearing at
the top of the list were all from today.

In any case,  the FSK signal is part of Marine DSC and it uses 1615 Hz
(1-bit) and 1785 Hz(0-bit) at 100 baud on HF and 1300 Hz and 2100 Hz at 1200
baud on VHF as the two tones.  I have an integrate and dump using matched
filters to distinguish between the two tones.  But strong low frequency
signals can mess it up, so I want to clean up the signal before it goes into
the Integrate and dump.

Now not only to I have to detect the signal but I have to decode it to see
if it has the correct DSC signature.  If it does not, then I procede with
the scanning and go to the next channel.  On VHF, there is only one channel
so there is no scanning problem...thank god; the speeds are awfully fast.

Right now I simply multiply the incoming signal by the sine and cosine of
both tones over a single baud pulse (giving a one baud delay after tuning to
a new channel) and compute which tone gives the strongest signal.  Its very
easy onthe CPU since it is a running integral and only one new integration
step is done each tap (the new integration step replaces the oldest). THe
scheme works quite well if the noise amplitude is on the same order as the
signal, but if lots of noise comes in especially at low frequencies, there
are difficulties. If I sing the correct tones using a mike I can really
swamp the signal, but I don't think there is anything I can do about that.

What I was going to do was to superpose two band pass FIR filters, one
centered on each of the frequencies to get rid of as much junk as possible
before applying the integrate and dump stuff. However, the filters are
looking pretty hefty in terms of taps.

I have looked at the Goertzel (sp?) algorithm and that seems to be a very
efficient way for tone detecting, but I don't appear to have the brains to
figure out how to convert the algorithm into a filter (it's very efficient
and takes few taps though it does take a little accumulation time before the
tone is recognized).  There is probably something I could use there, but I
don't know what!

In any case, that is the status.  I apologize for the extra post...it was an
error.

BR,

Brian

Dear Brian,

> Now I see the problem.  I never thought my first message got posted.  So I
> posted it again today.  And I thought it didn't get posted either but I
> couldn't beleive it would happen again.

This problem is solved in each modem
but in them some things are.
I prefere to look at the TI Application notes, where
is described how to solve such problems in modems.
The main problem is
that the signal during the bod period has a few waves,
and the usual filters and FFT do not work helpfully.
As to filters
I prefere the bandpass/bandstop filters based on the allpass filters,
which have very short delay, are quick, are easily dynamically tuned,
are more precise and sharp than biquadrat ones .

Regards,
A.Ser.

"Brian Reinhold" <breinhold@comcast.net> wrote in message
news:U9ILb.8460$Rc4.33990@attbi_s54...
> Now I see the problem.  I never thought my first message got posted.  So I
> posted it again today.  And I thought it didn't get posted either but I
> couldn't beleive it would happen again.  But now I have found it.  I have
> always had the messages ordered by time, but somehow they have gotten
> ordered by something else, and my posts were way down the list.  It was a
> stupid mistake; also enhanced by coincidence that the messages appearing
at
> the top of the list were all from today.
>
> In any case,  the FSK signal is part of Marine DSC and it uses 1615 Hz
> (1-bit) and 1785 Hz(0-bit) at 100 baud on HF and 1300 Hz and 2100 Hz at
1200
> baud on VHF as the two tones.  I have an integrate and dump using matched
> filters to distinguish between the two tones.  But strong low frequency
> signals can mess it up, so I want to clean up the signal before it goes
into
> the Integrate and dump.
>
> Now not only to I have to detect the signal but I have to decode it to see
> if it has the correct DSC signature.

Brian,

Well, I'm not the expert on FSK or scanning but here are some areas you may
want to consider:

The frequency separation of the two tones is 170 Hz.  To distinguish between
them requires a bandpass filter that cuts off pretty well after 170Hz
bandwidth - or a narrower filter than that!  Such a filter has a time
constant around 6msec. I believe.  This means that you can scan at around
170Hz/6msec = 28.33kHz/second which seems a bit slow to me but I don't know
your system parameters well enough to judge.
[This is based on the idea that you have to "dwell" for one time constant of
the filter in order to see an output given there is a signal present - it
could practically be a bit slower than this.]

Scanning would be faster with a wider filter.  I would be tempted to do
something like this:
Scan with a bandwidth of 1kHz at a rate of 1MHz/second.  Note that the scan
rate increases as the square of the filter bandwidth - so increasing the
bandwidth will improve the scan rate considerably.
When something is detected with such a wider band filter, stop long enough
to run the signal through a separate FSK code detector.  If the code is
detected, stop scanning.  If the code is not detected, resume scanning
without sounding the alarm.

Fred

Fred,

Is there a theorem which states that the time it takes to implement a filter
of width 'x' Hz is 1/x of a second?  Some IIR filters seem a lot better than
that, though it does seem that FIR filters are at least proportional to that
value.

THat would say that the delay caused by a filter with a 170 Hz bandwidth
would be (1/170)th of a second or 5.88 millseconds as you stated. Of course,
there are more problems with scanning as you have to detect a minimum string
of tones at the correct baud rate to be sure that it is not garbage. 6 ms at
a sampling rate of 42000 Hz would be 248 taps. That's quite a load!

Brian

"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
news:wNqdnX-JiJ7dypnd4p2dnA@centurytel.net...
>
> "Brian Reinhold" <breinhold@comcast.net> wrote in message
> news:U9ILb.8460$Rc4.33990@attbi_s54...
> > Now I see the problem.  I never thought my first message got posted.  So
I
> > posted it again today.  And I thought it didn't get posted either but I
> > couldn't beleive it would happen again.  But now I have found it.  I
have
> > always had the messages ordered by time, but somehow they have gotten
> > ordered by something else, and my posts were way down the list.  It was
a
> > stupid mistake; also enhanced by coincidence that the messages appearing
> at
> > the top of the list were all from today.
> >
> > In any case,  the FSK signal is part of Marine DSC and it uses 1615 Hz
> > (1-bit) and 1785 Hz(0-bit) at 100 baud on HF and 1300 Hz and 2100 Hz at
> 1200
> > baud on VHF as the two tones.  I have an integrate and dump using
matched
> > filters to distinguish between the two tones.  But strong low frequency
> > signals can mess it up, so I want to clean up the signal before it goes
> into
> > the Integrate and dump.
> >
> > Now not only to I have to detect the signal but I have to decode it to
see
> > if it has the correct DSC signature.
>
> Brian,
>
> Well, I'm not the expert on FSK or scanning but here are some areas you
may
> want to consider:
>
> The frequency separation of the two tones is 170 Hz.  To distinguish
between
> them requires a bandpass filter that cuts off pretty well after 170Hz
> bandwidth - or a narrower filter than that!  Such a filter has a time
> constant around 6msec. I believe.  This means that you can scan at around
> 170Hz/6msec = 28.33kHz/second which seems a bit slow to me but I don't
know
> your system parameters well enough to judge.
> [This is based on the idea that you have to "dwell" for one time constant
of
> the filter in order to see an output given there is a signal present - it
> could practically be a bit slower than this.]
>
> Scanning would be faster with a wider filter.  I would be tempted to do
> something like this:
> Scan with a bandwidth of 1kHz at a rate of 1MHz/second.  Note that the
scan
> rate increases as the square of the filter bandwidth - so increasing the
> bandwidth will improve the scan rate considerably.
> When something is detected with such a wider band filter, stop long enough
> to run the signal through a separate FSK code detector.  If the code is
> detected, stop scanning.  If the code is not detected, resume scanning
> without sounding the alarm.
>
> Fred
>
>

"Brian Reinhold" <breinhold@comcast.net> wrote in message
news:ByaNb.49543$5V2.65582@attbi_s53...
> Fred,
>
> Is there a theorem which states that the time it takes to implement a
filter
> of width 'x' Hz is 1/x of a second?  Some IIR filters seem a lot better
than
> that, though it does seem that FIR filters are at least proportional to
that
> value.
>
> THat would say that the delay caused by a filter with a 170 Hz bandwidth
> would be (1/170)th of a second or 5.88 millseconds as you stated. Of
course,
> there are more problems with scanning as you have to detect a minimum
string
> of tones at the correct baud rate to be sure that it is not garbage. 6 ms
at
> a sampling rate of 42000 Hz would be 248 taps. That's quite a load!
>
> Brian

Brian,

Well, you could call it "delay" but it's actually the response time.  I
don't know offhand of a nice neat "theorem" but the analysis goes something
like this:

A perfect lowpass filter will have a time domain impulse response that's
shaped as sin(x)/x with its width related to the filter bandwidth.  If you
pass a unit step into that filter, the response is the convolution of the
impulse response and the step input.  A little mental math shows that the
long-time response approaches the integral of the impulse response.  And,
the major contribution to the integral is the major lobe or peak of the
sin(x)/x.  So, the rise from around zero to around the final value happens
in a time that's close to the width of the main lobe of the sin(x)/x.  You
can fiddle with the filter as much as you want and this response time
characteristic won't change much.  All you can change is whether there's
overshoot or not, etc. but the time it takes is the time it takes.  So,
whether it's exactly sin(x)/x or something just close to it doesn't matter
much.
The narrower the filter, the broader the sin(x)/x and the longer it takes to
reach steady state at the output.

For a bandpass filter it is exactly the same except, we normally state the
bandwidth of a bandpass filter as 2x the bandwidth of a lowpass.  So, the
time response is 2x slower than you'd get by using the full bandpass width.
It appears that I erred by a factor of 2 in my last post and the speeds
would be 2x slower.  (Well, at least I think I now have it correct).

Example:  A bandpass filter at .25Hz with a bandwidth of 1/16th of 0.25 =
0.0156Hz ... 0.0156/2=0.0078125 whose reciprocal is 128 seconds - which is
roughly the time it takes for the filter to respond to 2/3 its final value
with a step change in the input amplitude of an in-band sinusoid.  It's easy
to demonstrate this by passing a sinusoidal pulse through the filter of
choice - and measuring the response time of the output.

FIR filters have to be long (in time) in order to be narrow (in frequency).
IIR filters have to have long impulse responses (really unit sample
responses) in time to be narrow in frequency just as well - even though the
number of coefficients may be much smaller than for the FIR.  After all,
there's a duality between time and frequency and we shouldn't expect the
implementation to have much of a practical affect on this.

So, FIR or IIR doesn't matter much if the concern is the response time.  FIR
or IIR matters more when you're concerned with computational load per output
sample.  And there are other considerations in choosing one over the
other....  For example, you can't do an FFT/IFFT frequency domain
multiplication implementation of the temporal convolution of an IIR, only
for a FIR.  An attempt to do so would start by changing the IIR impulse
response to a FIR representation - because the FFT is finite and can't deal
exactly with the infinite response of the IIR.

Probably a bigger affect is whether a FIR is linear phase or not.  Linear
phase design can take as many as 2x the number of coefficients - as a gross
approximation - for the same amplitude response.  In practice, the ratio
isn't necessarily so large.

I remain concerned that you still seem to want to scan and detect in the
same process when scanning alone might allow a wider bandwidth and allow a
faster scan rate - to be followed by an occasional stop-scan and detect
process.  Seems this would be much faster.  It's sort of a prioritization
method that puts time where you most need it.  No signal, no detection
analysis, faster scanning.  Signal present, do detection analysis.  This in
contrast to "do detection analysis all the time" which comes at the expense
of scan rate.

Fred

On Wed, 14 Jan 2004 12:25:05 GMT, "Brian Reinhold"
<breinhold@comcast.net> wrote:

>Fred,
>
>Is there a theorem which states that the time it takes to implement a filter
>of width 'x' Hz is 1/x of a second?  Some IIR filters seem a lot better than
>that, though it does seem that FIR filters are at least proportional to that
>value.

Hi Brian,

  such a great question, ... the answer of 
which I don't know off the top of my head.

But what I think we should say is that the 
time delay through a linear-phase 
nonrecursive FIR filter is roughly proportional 
to the reciprocal of the filter transition 
region width, and not its passband width.

[-Rick-]

"Brian Reinhold" <breinhold@comcast.net> wrote in message
news:ByaNb.49543$5V2.65582@attbi_s53...
>
> Is there a theorem which states that the time it takes to implement a
filter
> of width 'x' Hz is 1/x of a second?  Some IIR filters seem a lot better
than
> that, though it does seem that FIR filters are at least proportional to
that
> value.

Hello Brian,
While there isn't a theorem that says exactly what you ask above, there are
some theorems that let you see highly related properties.

First a scaling theorem

                        1
f(at)    <==>   --- F(w/a)
                       |a|

where f() and F() are a Fourier pair. So here you can see a reciprocal
relationship. So if you squeeze a time domain response for a function into a
tighter time frame, then its frequency response expands out to occupy more
bandwidth.

Another theorem sometimes called the "bandwidth" theorem is given by  (delta
t)*(delta w) >= gamma

where the delta signifies an effective span and gamma is a fixed constant.

A common delta method is finding the standard deviation of the magnitude
square of the function. In this case gamma is simply 1/2. And this approach
is applicable to finite energy functions. Notice how the theorem is an
inequality in terms of gamma. This means some functions can have a tightest
support in both domains simultaneously while others are worse.

Example, let your function be a gaussian pulse, i.e.,  f(t) = exp(-a*t^2),

then  its fourier transform is F(w) = sqrt(pi/a)exp(-(w^2)/(4a))

If you find the second moments about the mean of each of these (the standard
deviation) and find their product,
you will result in exactly 1/2. This is an example of a minimum uncertainty
function.

The reason for using a moment for measuring the spread is you get a finite
value for a function that has infinite support. These gaussian functions are
nonzero everywhere (real arguments).

So when one uses a rule of thumb to reciprocate the time domain width to
find the bandwidth, then you can see by the above theorem that this is only
an approximation since in general you don't know if your function is going
to be a minimum uncertainty function such as the gaussian above.

But as both as these theorems state there is an inherent inverse
relationship between the "width" of the function and the "width" of the
fourier transform of the same function.

So I hope this helps to answer your problem.


Clay

"Rick Lyons" <r.lyons@REMOVE.ieee.org> wrote in message
news:40067255.50327296@news.west.earthlink.net...
> On Wed, 14 Jan 2004 12:25:05 GMT, "Brian Reinhold"
> <breinhold@comcast.net> wrote:
>
> >Fred,
> >
> >Is there a theorem which states that the time it takes to implement a
filter
> >of width 'x' Hz is 1/x of a second?  Some IIR filters seem a lot better
than
> >that, though it does seem that FIR filters are at least proportional to
that
> >value.
>
> Hi Brian,
>
>   such a great question, ... the answer of
> which I don't know off the top of my head.
>
> But what I think we should say is that the
> time delay through a linear-phase
> nonrecursive FIR filter is roughly proportional
> to the reciprocal of the filter transition
> region width, and not its passband width.

Rick,

The time delay through a linear phase FIR filter is 1/2 the length of the
filter isn't it?  Well, it is for a lowpass I believe.

The transition width in frequency is a function of (is limited in how small
it can be) by what we might call the "principal temporal width" (the
distance over which most of the energy resides).
And, the transition width in time is a function of (is limited in how small
it can be) by what we might call the "principal spectral width" i.e.
"bandwidth".

Call the sample interval 1.0 seconds / sample rate 1Hz just for convenience.
Actually, I apologize for this because the numbers aren't very typical -
just note that this way everything is normalized to the sample interval and
can be changed by multiplying or dividing by the sample interval.

Let's say we have a causal linear phase lowpass filter of length 4096
seconds, N=4096.
The frequency sample interval is 1/4096 Hz.
Let's make the filter a lowpass with band edge at 256 frequency samples or
256/4096 Hz.
Let's make the frequency transition width be 32 samples or 32/4096 Hz.

With this, here's what we get:

The unit sample response will be centered at 2048 seconds and will look like
a sin(kt)/kt.
It will be very small at the ends.

Then:
- The "principal temporal width" will be determined by the *bandwidth* of
the filter. It will be roughly 4096/256
= 16 seconds or 256 time samples.
- accordingly, the time transition or step response time will be
approximately 16 seconds.
- the "bulk" delay of the filter will be 2048 seconds as above
- the frequency transition width of the filter, at best, can be
approximately 1/4096 Hz which is the reciprocal of the length of the filter.
We selected 32/4096 so this means that the filter can be shortened from
length 4096 to length 4096/32=128.

If we simplify this into "sinc cartoons":
- there is a sinc in time that's related to the width of the filter /
bandwidth.
- and, there is a sinc in frequency that's related to the temporal length of
the filter and the transition width in frequency.

So, you are right if you qualified your statement as follows:
I want a lowpass filter that allows a frequency transition width of 32
samples out of 4096.
I will design the shortest filter possible to achieve this.
I end up with a filter of length 256 - which has a delay of 128 seconds.
This way I've created a connection between the transition width and the
delay.  As a practical matter, this is no doubt often the case because the
transition width can drive the filter design, hence its length, hence its
delay.  I guess my point is about cause and effect.  If you start with an
adequate length, thus delay, then the transition width doesn't drive the
design and is no longer tied to the delay.  The connection is in the design
process and not in the physics.  picky, picky, eh?

... and I'm off by one or two factors of 2 somewhere here!!


Now, to the point of this thread about scanning:

If one is scanning with filter something like the one above, there will be a
delay of the latency or bulk delay type of 2048 seconds.  There will also be
a time response of 16 seconds - which is the dwell time necessary to detect
the presence of a signal - which might be viewed as a delay of sorts.

So, in order to scan effectively, the dwell time needs to be >16 seconds in
a 256/4096 Hz band and the delay will be 2048 seconds (for the long filter)
from the time an "event" occurs and the time we see it at the output.
This suggests a scanner design that would "jump back" 16 "bins" or
16*256/4096 = 1Hz in frequency when a detection occurs .... well something
like that - because the event took place earlier in the scan process.  I'm
not being too careful about the numbers here just to convey the ideas.
Caveat lector.

Fred